idnits 2.17.1 draft-ietf-regext-allocation-token-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 18, 2017) is 2372 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) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track K. Feher 5 Expires: April 21, 2018 Neustar 6 October 18, 2017 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-04 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension for including an allocation token or code for allocating an 16 object like a domain name to the client. The allocation token MAY be 17 transferred out-of-band to a client to give them authorization to 18 allocate an object using one of the EPP transform commands including 19 create, update, and transfer. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 3 59 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 63 3.1.3. EPP Command . . . . . . . . . . . . . . . 10 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . 11 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . 12 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 12 68 3.2.4. EPP Command . . . . . . . . . . . . . . . 12 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . 13 70 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. Allocation Token Extension Schema . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 74 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 76 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 17 77 6.2. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 17 78 6.3. Neustar gTLD SRS . . . . . . . . . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 9. Normative References . . . . . . . . . . . . . . . . . . . . 18 82 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 83 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 84 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 85 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 19 86 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 19 87 A.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 19 88 A.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 19 89 A.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 19 90 A.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 20 91 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 This document describes an extension mapping for version 1.0 of the 97 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 98 extension to EPP object mappings like the EPP domain name mapping 99 [RFC5731], for passing an allocation token one of the EPP transform 100 commands including create, update, and transfer. The allocation 101 token is known to the server to authorize a client that passes a 102 matching allocation token with one of the supported EPP transform 103 commands. It is up to server policy which EPP transform commands and 104 which objects support the allocation token. The allocation token MAY 105 be returned to an authorized client for passing out-of-band to a 106 client that uses it with an EPP transform command. 108 1.1. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 XML is case sensitive. Unless stated otherwise, XML specifications 115 and examples provided in this document MUST be interpreted in the 116 character case presented in order to develop a conforming 117 implementation. 119 In examples, "C:" represents lines sent by a protocol client and "S:" 120 represents lines returned by a protocol server. Indentation and 121 white space in examples are provided only to illustrate element 122 relationships and are not a REQUIRED feature of this protocol. 124 "allocationToken-1.0" is used as an abbreviation for 125 "urn:ietf:params:xml:ns:allocationToken-1.0". The XML namespace 126 prefix "allocationToken" is used, but implementations MUST NOT depend 127 on it and instead employ a proper namespace-aware XML parser and 128 serializer to interpret and output the XML documents. 130 2. Object Attributes 132 This extension adds additional elements to EPP object mappings like 133 the EPP domain name mapping [RFC5731]. Only those new elements are 134 described here. 136 2.1. Allocation Token 138 The Allocation Token is a simple XML "token" type. The exact format 139 of the Allocation Token is up to server policy. The server MUST have 140 the allocation token for each object to match against the allocation 141 token passed by the client to authorize the allocation of the object. 143 The same element is used for all of 144 the supported EPP transform commands as well as the info response. 145 If an invalid allocation token is passed the server MUST return an 146 EPP error result code of 2201. 148 An example element with value of 149 "abc123": 151 153 abc123 154 156 3. EPP Command Mapping 158 A detailed description of the EPP syntax and semantics can be found 159 in the EPP core protocol specification [RFC5730]. 161 3.1. EPP Query Commands 163 EPP provides three commands to retrieve object information: 164 to determine if an object is known to the server, to retrieve 165 detailed information associated with an object, and to 166 retrieve object transfer status information. 168 3.1.1. EPP Command 170 This extension defines additional elements to extend the EPP 171 command of an object mapping like [RFC5731]. 173 This extension allow clients to check the availability of an object 174 with an allocation token, as described in Section 2.1. Clients can 175 check if an object can be created using the allocation token. The 176 allocation token is applied to all object names included in the EPP 177 command. 179 Example command for the example.tld domain name using the 180 extension with the allocation token 181 of 'abc123': 183 C: 184 C: 185 C: 186 C: 187 C: 189 C: example.tld 190 C: 191 C: 192 C: 193 C: 196 C: abc123 197 C: 198 C: 199 C: ABC-12345 200 C: 201 C: 203 If the query was successful, the server replies with an 204 response providing availability status of queried object. 206 Example domain response for a command using the 207 extension: 209 S: 210 S: 211 S: 212 S: 213 S: Command completed successfully 214 S: 215 S: 216 S: 218 S: 219 S: example.tld 220 S: Invalid domain-token pair 221 S: 222 S: 223 S: 224 S: 225 S: ABC-DEF-12345 226 S: 54321-XYZ 227 S: 228 S: 229 S: 230 Example command with the 231 extension for the example.tld and example2.tld domain names. 232 Availability of example.tld and example2.tld domain names are based 233 on the allocation token 'abc123': 235 C: 236 C: 237 C: 238 C: 239 C: 241 C: example.tld 242 C: example2.tld 243 C: 244 C: 245 C: 246 C: 249 C: abc123 250 C: 251 C: 252 C: ABC-DEF-12345 253 C: 254 C: 255 Example domain response for multiple domain names in the 256 command using the 257 extension: 259 S: 260 S: 261 S: 262 S: 263 S: Command completed successfully 264 S: 265 S: 266 S: 268 S: 269 S: example.tld 270 S: Invalid domain-token pair 271 S: 272 S: 273 S: example2.tld 274 S: 275 S: 276 S: 277 S: 278 S: ABC-DEF-12345 279 S: 54321-XYZ 280 S: 281 S: 282 S: 284 This extension does not add any elements to the EPP response 285 described in the [RFC5730]. 287 3.1.2. EPP Command 289 This extension defines additional elements to extend the EPP 290 command of an object mapping like [RFC5731]. 292 The EPP command allows a client to request information on an 293 existing object. Authorized clients MAY retrieve the allocation 294 token (Section 2.1) along with the other object information using the 295 element that identifies the extension 296 namespace. The element is an empty element 297 that serves as a marker to the server to return the 298 element, defined in Section 2.1, in 299 the info response. If the client is not authorized to receive the 300 allocation token (Section 2.1), the server MUST return an EPP error 301 result code of 2201. If the client is authorized to receive the 302 allocation token (Section 2.1), but there is no allocation token 303 (Section 2.1) associated with the object, the server MUST return an 304 EPP error result code of 2303 object referencing the 305 element. 307 Example command with the allocationToken:info extension for 308 the example.tld domain name: 310 C: 311 C: 312 C: 313 C: 314 C: 318 C: example.tld 319 C: 320 C: 321 C: 322 C: 325 C: 326 C: ABC-12345 327 C: 328 C: 330 If the query was successful, the server replies with an 331 element, as described in 332 Section 2.1. 334 Example domain response using the 335 extension: 337 S: 338 S: 339 S: 340 S: 341 S: Command completed successfully 342 S: 343 S: 344 S: 346 S: example.tld 347 S: EXAMPLE1-REP 348 S: 349 S: jd1234 350 S: sh8013 351 S: sh8013 352 S: ClientX 353 S: ClientY 354 S: 2012-04-03T22:00:00.0Z 355 S: 356 S: 2fooBAR 357 S: 358 S: 359 S: 360 S: 361 S: 364 S: abc123 365 S: 366 S: 367 S: 368 S: ABC-12345 369 S: 54321-XYZ 370 S: 371 S: 372 S: 374 3.1.3. EPP Command 376 This extension does not add any elements to the EPP query 377 command or response described in the [RFC5730]. 379 3.2. EPP Transform Commands 381 EPP provides five commands to transform objects: to create 382 an instance of an object, to delete an instance of an 383 object, to extend the validity period of an object, 384 to manage object sponsorship changes, and to 385 change information associated with an object. 387 3.2.1. EPP Command 389 This extension defines additional elements to extend the EPP 390 command of an object mapping like [RFC5731]. 392 The EPP command provides a transform operation that allows a 393 client to create an object. In addition to the EPP command elements 394 described in an object mapping like [RFC5731], the command MUST 395 contain a child element, as defined 396 in Section 2.1, that identifies the extension namespace for the 397 client to be authorized to create and allocate the object. If the 398 allocation token (Section 2.1) does not match the object's allocation 399 token (Section 2.1), the server MUST return an EPP error result code 400 of 2201.: 402 Example command to create a domain object with an allocation 403 token: 405 C: 406 C: 407 C: 408 C: 409 C: 411 C: example.tld 412 C: jd1234 413 C: sh8013 414 C: sh8013 415 C: 416 C: 2fooBAR 417 C: 418 C: 419 C: 420 C: 421 C: 424 C: abc123 425 C: 426 C: 427 C: ABC-12345 428 C: 429 C: 431 This extension does not add any elements to the EPP response 432 described in the [RFC5730]. 434 3.2.2. EPP Command 436 This extension does not add any elements to the EPP command 437 or response described in the [RFC5730]. 439 3.2.3. EPP Command 441 This extension does not add any elements to the EPP command 442 or response described in the [RFC5730]. 444 3.2.4. EPP Command 446 This extension defines additional elements to extend the EPP 447 request command of an object mapping like [RFC5731]. 449 The EPP request command provides a transform operation 450 that allows a client to request the transfer of an object. In 451 addition to the EPP command elements described in an object mapping 452 like [RFC5731], the command MUST contain a child 453 element, as defined in Section 2.1, 454 that identifies the extension namespace for the client to be 455 authorized to transfer and allocate the object. If the allocation 456 token (Section 2.1) does not match the object's allocation token 457 (Section 2.1), the server MUST return an EPP error result code of 458 2201.: 460 Example request command to allocate the domain object with 461 the allocation token: 463 C: 464 C: 465 C: 466 C: 467 C: 469 C: example1.tld 470 C: 1 471 C: 472 C: 2fooBAR 473 C: 474 C: 475 C: 476 C: 477 C: 480 C: abc123 481 C: 482 C: 483 C: ABC-12345 484 C: 485 C: 487 This extension does not add any elements to the EPP 488 response described in the [RFC5730]. 490 3.2.5. EPP Command 492 This extension defines additional elements to extend an extension of 493 an empty EPP command of an object mapping like [RFC5731]. 494 An example of an extension of an empty EPP command is the 495 definition of the restore command within [RFC3915]. 497 An extension of an empty EPP command defines a new verb that 498 transforms an object. In addition to the EPP command elements 499 described in an object mapping like [RFC5731], the command MUST 500 contain a child element, as defined 501 in Section 2.1, that identifies the extension namespace for the 502 client to be authorized to allocate the object. If the allocation 503 token (Section 2.1) does not match the object's allocation token 504 (Section 2.1), the server MUST return an EPP error result code of 505 2201.: 507 Example use an extension of an empty command to release a 508 domain object with an allocation token: 510 C: 511 C: 512 C: 513 C: 514 C: 516 C: example1.tld 517 C: 518 C: 519 C: 520 C: 522 C: 525 C: abc123 526 C: 527 C: 528 C: ABC-12345-XYZ 529 C: 530 C: 532 This extension does not add any elements to the EPP response 533 described in the [RFC5730]. 535 4. Formal Syntax 537 One schema is presented here that is the EPP Allocation Token 538 Extension schema. 540 The formal syntax presented here is a complete schema representation 541 of the object mapping suitable for automated validation of EPP XML 542 instances. The BEGIN and END tags are not part of the schema; they 543 are used to note the beginning and ending of the schema for URI 544 registration purposes. 546 4.1. Allocation Token Extension Schema 548 BEGIN 549 551 556 557 558 Extensible Provisioning Protocol v1.0 559 Allocation Token Extension. 560 561 563 564 566 568 571 572 573 574 575 577 578 579 END 581 5. IANA Considerations 583 5.1. XML Namespace 585 This document uses URNs to describe XML namespaces and XML schemas 586 conforming to a registry mechanism described in [RFC3688]. The 587 following URI assignment is requested of IANA: 589 URI: ietf:params:xml:ns:allocationToken-1.0 591 Registrant Contact: See the "Author's Address" section of this 592 document. 594 XML: See the "Formal Syntax" section of this document. 596 5.2. EPP Extension Registry 598 The EPP extension described in this document should be registered by 599 the IANA in the EPP Extension Registry described in [RFC7451]. The 600 details of the registration are as follows: 602 Name of Extension: "Allocation Token Extension for the Extensible 603 Provisioning Protocol (EPP)" 605 Document status: Standards Track 607 Reference: (insert reference to RFC version of this document) 609 Registrant Name and Email Address: IESG, 611 TLDs: Any 613 IPR Disclosure: None 615 Status: Active 617 Notes: None 619 6. Implementation Status 621 Note to RFC Editor: Please remove this section and the reference to 622 RFC 6982 [RFC6982] before publication. 624 This section records the status of known implementations of the 625 protocol defined by this specification at the time of posting of this 626 Internet-Draft, and is based on a proposal described in RFC 6982 627 [RFC6982]. The description of implementations in this section is 628 intended to assist the IETF in its decision processes in progressing 629 drafts to RFCs. Please note that the listing of any individual 630 implementation here does not imply endorsement by the IETF. 631 Furthermore, no effort has been spent to verify the information 632 presented here that was supplied by IETF contributors. This is not 633 intended as, and must not be construed to be, a catalog of available 634 implementations or their features. Readers are advised to note that 635 other implementations may exist. 637 According to RFC 6982 [RFC6982], "this will allow reviewers and 638 working groups to assign due consideration to documents that have the 639 benefit of running code, which may serve as evidence of valuable 640 experimentation and feedback that have made the implemented protocols 641 more mature. It is up to the individual working groups to use this 642 information as they see fit". 644 6.1. Verisign EPP SDK 646 Organization: Verisign Inc. 648 Name: Verisign EPP SDK 650 Description: The Verisign EPP SDK includes both a full client 651 implementation and a full server stub implementation of draft-ietf- 652 regext-allocation-token. 654 Level of maturity: Production 656 Coverage: All aspects of the protocol are implemented. 658 Licensing: GNU Lesser General Public License 660 Contact: jgould@verisign.com 662 URL: https://www.verisign.com/en_US/channel-resources/domain- 663 registry-products/epp-sdks 665 6.2. Neustar EPP SDK 667 Organisation: Neustar Inc. 669 Name: Neustar EPP SDK 671 Description: The Neustar EPP SDK includes a full client 672 implementation of draft-ietf-regext-allocation-token. 674 Level of maturity: Production 676 Coverage: All aspects of the protocol are implemented. 678 Licensing: GNU Lesser General Public License 680 Contact: kal.feher@team.neustar 682 URL: http://registrytoolkit.neustar 684 6.3. Neustar gTLD SRS 686 Organisation: Neustar Inc. 688 Name: Neustar generic Top Level Domain (gTLD) Shared Registry System 689 (SRS). 691 Description: The Neustar gTLD SRS implements the server side of 692 draft-ietf-regext-allocation-token. For several Top Level Domains 694 Level of maturity: Production 696 Coverage: All server side aspects of the protocol are implemented. 698 Licensing: Proprietary 700 Contact: kal.feher@team.neustar 702 7. Security Considerations 704 The mapping extensions described in this document do not provide any 705 security services beyond those described by EPP [RFC5730] and 706 protocol layers used by EPP. The security considerations described 707 in these other specifications apply to this specification as well. 709 8. Acknowledgements 711 The authors wish to acknowledge the original concept for this draft 712 and the efforts in the initial versions of this draft by Trung Tran 713 and Sharon Wodjenski. 715 9. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, . 722 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 723 DOI 10.17487/RFC3688, January 2004, . 726 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 727 the Extensible Provisioning Protocol (EPP)", RFC 3915, 728 DOI 10.17487/RFC3915, September 2004, . 731 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 732 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 733 . 735 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 736 Domain Name Mapping", STD 69, RFC 5731, 737 DOI 10.17487/RFC5731, August 2009, . 740 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 741 Code: The Implementation Status Section", RFC 6982, 742 DOI 10.17487/RFC6982, July 2013, . 745 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 746 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 747 February 2015, . 749 Appendix A. Change History 751 A.1. Change from 00 to 01 753 1. Amended XML Namespace section of IANA Considerations, added EPP 754 Extension Registry section. 755 2. Moved Change History to the back section as an Appendix. 757 A.2. Change from 01 to 02 759 1. Ping update. 761 A.3. Change from 02 to 03 763 1. Ping update. 765 A.4. Change from 03 to 04 767 1. Updated the authors for the draft. 769 A.5. Change from 04 to REGEXT 00 771 1. Changed to regext working group draft by changing draft-gould- 772 allocation-token to draft-ietf-regext-allocation-token. 774 A.6. Change from REGEXT 00 to REGEXT 01 776 1. Ping update. 778 A.7. Change from REGEXT 01 to REGEXT 02 780 1. Added the Implementation Status section. 782 A.8. Change from REGEXT 02 to REGEXT 03 784 1. Changed Neustar author to Kal Feher. 786 A.9. Change from REGEXT 03 to REGEXT 04 788 1. Added Neustar implementation to the Implementation Status 789 section. 791 Authors' Addresses 793 James Gould 794 VeriSign, Inc. 795 12061 Bluemont Way 796 Reston, VA 20190 797 US 799 Email: jgould@verisign.com 800 URI: http://www.verisigninc.com 802 Kal Feher 803 Neustar 804 lvl 8/10 Queens Road 805 Melbourne, VIC 3004 806 AU 808 Email: kal.feher@team.neustar 809 URI: http://www.neustar.biz