idnits 2.17.1 draft-ietf-regext-allocation-token-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 16, 2018) is 2172 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. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track K. Feher 5 Expires: November 17, 2018 Neustar 6 May 16, 2018 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-08 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension for including an Allocation Token in query and transform 16 commands. The Allocation Token is used as a credential that 17 authorizes a client to request the allocation of a specific object 18 from the server, using one of the EPP transform commands including 19 create 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 November 17, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 4 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 Query 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 . . . . . . . . . . . . 14 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 74 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 15 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 16 77 6.2. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 16 78 6.3. Neustar gTLD SRS . . . . . . . . . . . . . . . . . . . . 17 79 6.4. Net::DRI . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 84 9.2. Informative References . . . . . . . . . . . . . . . . . 19 85 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 86 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 87 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 88 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 19 89 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 19 90 A.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 20 91 A.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 20 92 A.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 20 93 A.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 20 94 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 20 95 A.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 20 96 A.11. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 20 97 A.12. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 22 98 A.13. Change from REGEXT 07 to REGEXT 08 . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 This document describes an extension mapping for version 1.0 of the 104 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 105 extension to EPP object mappings like the EPP domain name mapping 106 [RFC5731], supports passing an Allocation Token as a credential that 107 authorizes a client to request the allocation of a specific object 108 from the server, using one of the EPP transform commands including 109 create and transfer. 111 Allocation is when a server assigns the sponsoring client of an 112 object based on the use of an Allocation Token credential. Examples 113 include allocating a registration based on a pre-eligibility 114 Allocation Token, allocating a premium domain name registration based 115 on an auction Allocation Token, allocating a registration based on a 116 founders Allocation Token, and allocating an existing domain name 117 held by the server or by a different sponsoring client based on an 118 Allocation Token passed with a transfer command. 120 A client MUST pass an Allocation Token known to the server to be 121 authorized to use one of the supported EPP transform commands. It is 122 up to server policy which EPP transform commands and which objects 123 require the Allocation Token. The Allocation Token MAY be returned 124 to an authorized client for passing out-of-band to a client that uses 125 it with an EPP transform command. 127 1.1. Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 XML is case sensitive. Unless stated otherwise, XML specifications 134 and examples provided in this document MUST be interpreted in the 135 character case presented in order to develop a conforming 136 implementation. 138 In examples, "C:" represents lines sent by a protocol client and "S:" 139 represents lines returned by a protocol server. Indentation and 140 white space in examples are provided only to illustrate element 141 relationships and are not a REQUIRED feature of this protocol. 143 "allocationToken-1.0" is used as an abbreviation for 144 "urn:ietf:params:xml:ns:allocationToken-1.0". The XML namespace 145 prefix "allocationToken" is used, but implementations MUST NOT depend 146 on it and instead employ a proper namespace-aware XML parser and 147 serializer to interpret and output the XML documents. 149 2. Object Attributes 151 This extension adds additional elements to EPP object mappings like 152 the EPP domain name mapping [RFC5731]. Only those new elements are 153 described here. 155 2.1. Allocation Token 157 The Allocation Token is a simple XML "token" type. The exact format 158 of the Allocation Token is up to server policy. The server MUST have 159 the Allocation Token for each object to match against the Allocation 160 Token passed by the client to authorize the allocation of the object. 161 The element is used for all of the 162 supported EPP commands as well as the info response. If the 163 Allocation Token passed to the server does not apply to the object, 164 the server MUST return an EPP error result code of 2201. 166 An example element with value of 167 "abc123": 169 171 abc123 172 174 3. EPP Command Mapping 176 A detailed description of the EPP syntax and semantics can be found 177 in the EPP core protocol specification [RFC5730]. 179 3.1. EPP Query Commands 181 EPP provides three commands to retrieve object information: 182 to determine if an object can be provisioned, to retrieve 183 information associated with an object, and to retrieve 184 object transfer status information. 186 3.1.1. EPP Command 188 This extension defines additional elements to extend the EPP 189 command of an object mapping like [RFC5731]. 191 This extension allow clients to check the availability of an object 192 with an Allocation Token, as described in Section 2.1. Clients can 193 check if an object can be created using the Allocation Token. The 194 Allocation Token is applied to all object names included in the EPP 195 command. 197 Example command for the example.tld domain name using the 198 extension with the allocation token 199 of 'abc123': 201 C: 202 C: 203 C: 204 C: 205 C: 207 C: example.tld 208 C: 209 C: 210 C: 211 C: 214 C: abc123 215 C: 216 C: 217 C: ABC-12345 218 C: 219 C: 221 If the query was successful, the server replies with a 222 response providing the availability status of the queried object 223 based on the following Allocation Token cases, where the object is 224 otherwise available: 226 1. If an object requires an Allocation Token and the Allocation 227 Token does apply to the object, then the server MUST return the 228 availability status as available (e.g., "avail" attribute is "1" 229 or "true"). 230 2. If an object requires an Allocation Token and the Allocation 231 Token does not apply to the object or an object does not require 232 an Allocation Token, then the server SHOULD return the 233 availability status as unavailable (e.g., "avail" attribute is 234 "0" or "false"). 236 Example domain response for a command using the 237 extension: 239 S: 240 S: 241 S: 242 S: 243 S: Command completed successfully 244 S: 245 S: 246 S: 248 S: 249 S: example.tld 250 S: Allocation Token mismatch 251 S: 252 S: 253 S: 254 S: 255 S: ABC-DEF-12345 256 S: 54321-XYZ 257 S: 258 S: 259 S: 260 Example command with the 261 extension for the example.tld and example2.tld domain names. 262 Availability of example.tld and example2.tld domain names are based 263 on the Allocation Token 'abc123': 265 C: 266 C: 267 C: 268 C: 269 C: 271 C: example.tld 272 C: example2.tld 273 C: 274 C: 275 C: 276 C: 279 C: abc123 280 C: 281 C: 282 C: ABC-DEF-12345 283 C: 284 C: 285 Example domain response for multiple domain names in the 286 command using the 287 extension: 289 S: 290 S: 291 S: 292 S: 293 S: Command completed successfully 294 S: 295 S: 296 S: 298 S: 299 S: example.tld 300 S: Allocation Token mismatch 301 S: 302 S: 303 S: example2.tld 304 S: 305 S: 306 S: 307 S: 308 S: ABC-DEF-12345 309 S: 54321-XYZ 310 S: 311 S: 312 S: 314 This extension does not add any elements to the EPP response 315 described in the [RFC5730]. 317 3.1.2. EPP Command 319 This extension defines additional elements to extend the EPP 320 command of an object mapping like [RFC5731]. 322 The EPP command allows a client to request information 323 associated with an existing object. Authorized clients MAY retrieve 324 the Allocation Token (Section 2.1) along with the other object 325 information using the element. The 326 element is an empty element that serves as a 327 marker to the server to return the 328 element in the info response. If the client is not authorized to 329 receive the Allocation Token, the server MUST return an EPP error 330 result code of 2201. If the client is authorized to receive the 331 Allocation Token, but there is no Allocation Token associated with 332 the object, the server MUST return an EPP error result code of 2303 333 object referencing the element. The 334 auhorization is subject to server policy. 336 Example command with the allocationToken:info extension for 337 the example.tld domain name: 339 C: 340 C: 341 C: 342 C: 343 C: 347 C: example.tld 348 C: 349 C: 350 C: 351 C: 354 C: 355 C: ABC-12345 356 C: 357 C: 359 If the query was successful, the server replies with an 360 element, as described in 361 Section 2.1. 363 Example domain response using the 364 extension: 366 S: 367 S: 368 S: 369 S: 370 S: Command completed successfully 371 S: 372 S: 373 S: 375 S: example.tld 376 S: EXAMPLE1-REP 377 S: 378 S: jd1234 379 S: sh8013 380 S: sh8013 381 S: ClientX 382 S: ClientY 383 S: 2012-04-03T22:00:00.0Z 384 S: 385 S: 2fooBAR 386 S: 387 S: 388 S: 389 S: 390 S: 393 S: abc123 394 S: 395 S: 396 S: 397 S: ABC-12345 398 S: 54321-XYZ 399 S: 400 S: 401 S: 403 3.1.3. EPP Query Command 405 This extension does not add any elements to the EPP query 406 command or query response described in the [RFC5730]. 408 3.2. EPP Transform Commands 410 EPP provides five commands to transform objects: to create 411 an instance of an object, to delete an instance of an 412 object, to extend the validity period of an object, 413 to manage object sponsorship changes, and to 414 change information associated with an object. 416 3.2.1. EPP Command 418 This extension defines additional elements to extend the EPP 419 command of an object mapping like [RFC5731]. 421 The EPP command provides a transform operation that allows a 422 client to create an instance of an object. In addition to the EPP 423 command elements described in an object mapping like [RFC5731], the 424 command MUST contain a child 425 element for the client to be authorized to create and allocate the 426 object. If the Allocation Token does not apply to the object, the 427 server MUST return an EPP error result code of 2201. 429 Example command to create a domain object with an Allocation 430 Token: 432 C: 433 C: 434 C: 435 C: 436 C: 438 C: example.tld 439 C: jd1234 440 C: sh8013 441 C: sh8013 442 C: 443 C: 2fooBAR 444 C: 445 C: 446 C: 447 C: 448 C: 451 C: abc123 452 C: 453 C: 454 C: ABC-12345 455 C: 456 C: 458 This extension does not add any elements to the EPP response 459 described in the [RFC5730]. 461 3.2.2. EPP Command 463 This extension does not add any elements to the EPP command 464 or response described in the [RFC5730]. 466 3.2.3. EPP Command 468 This extension does not add any elements to the EPP command 469 or response described in the [RFC5730]. 471 3.2.4. EPP Command 473 This extension defines additional elements to extend the EPP 474 request command of an object mapping like [RFC5731]. 476 The EPP request command provides a transform operation 477 that allows a client to request the transfer of an object. In 478 addition to the EPP command elements described in an object mapping 479 like [RFC5731], the command MUST contain a child 480 element for the client to be 481 authorized to transfer and allocate the object. The authorization 482 associated with the Allocation Token is in addition to and does not 483 replace the authorization mechanism defined for the object's 484 request command. If the Allocation Token does not apply 485 to the object, the server MUST return an EPP error result code of 486 2201. 488 Example request command to allocate the domain object with 489 the Allocation Token: 491 C: 492 C: 493 C: 494 C: 495 C: 497 C: example1.tld 498 C: 1 499 C: 500 C: 2fooBAR 501 C: 502 C: 503 C: 504 C: 505 C: 508 C: abc123 509 C: 510 C: 511 C: ABC-12345 512 C: 513 C: 515 This extension does not add any elements to the EPP 516 response described in the [RFC5730]. 518 3.2.5. EPP Command 520 This extension does not add any elements to the EPP command 521 or response described in the [RFC5730]. 523 4. Formal Syntax 525 One schema is presented here that is the EPP Allocation Token 526 Extension schema. 528 The formal syntax presented here is a complete schema representation 529 of the object mapping suitable for automated validation of EPP XML 530 instances. The BEGIN and END tags are not part of the schema; they 531 are used to note the beginning and ending of the schema for URI 532 registration purposes. 534 4.1. Allocation Token Extension Schema 536 BEGIN 537 538 545 546 547 Extensible Provisioning Protocol v1.0 548 Allocation 549 Token Extension. 550 551 553 554 556 558 562 563 564 565 566 568 569 570 END 572 5. IANA Considerations 574 5.1. XML Namespace 576 This document uses URNs to describe XML namespaces and XML schemas 577 conforming to a registry mechanism described in [RFC3688]. The 578 following URI assignment is requested of IANA: 580 Registration request for the allocationToken namespace: 582 URI: ietf:params:xml:ns:allocationToken-1.0 583 Registrant Contact: IESG 584 XML: None. Namespace URIs do not represent an XML specification. 586 Registration request for the allocationToken XML schema: 588 URI: ietf:params:xml:ns:allocationToken-1.0 589 Registrant Contact: IESG 590 XML: See the "Formal Syntax" section of this document. 592 5.2. EPP Extension Registry 594 The following registration of the EPP Extension Registry, described 595 in [RFC7451], is requested: 597 Name of Extension: "Allocation Token Extension for the Extensible 598 Provisioning Protocol (EPP)" 600 Document status: Standards Track 602 Reference: (insert reference to RFC version of this document) 604 Registrant Name and Email Address: IESG, 606 TLDs: Any 608 IPR Disclosure: None 610 Status: Active 612 Notes: None 614 6. Implementation Status 616 Note to RFC Editor: Please remove this section and the reference to 617 RFC 7942 [RFC7942] before publication. 619 This section records the status of known implementations of the 620 protocol defined by this specification at the time of posting of this 621 Internet-Draft, and is based on a proposal described in RFC 7942 622 [RFC7942]. The description of implementations in this section is 623 intended to assist the IETF in its decision processes in progressing 624 drafts to RFCs. Please note that the listing of any individual 625 implementation here does not imply endorsement by the IETF. 626 Furthermore, no effort has been spent to verify the information 627 presented here that was supplied by IETF contributors. This is not 628 intended as, and must not be construed to be, a catalog of available 629 implementations or their features. Readers are advised to note that 630 other implementations may exist. 632 According to RFC 7942 [RFC7942], "this will allow reviewers and 633 working groups to assign due consideration to documents that have the 634 benefit of running code, which may serve as evidence of valuable 635 experimentation and feedback that have made the implemented protocols 636 more mature. It is up to the individual working groups to use this 637 information as they see fit". 639 6.1. Verisign EPP SDK 641 Organization: Verisign Inc. 643 Name: Verisign EPP SDK 645 Description: The Verisign EPP SDK includes both a full client 646 implementation and a full server stub implementation of draft-ietf- 647 regext-allocation-token. 649 Level of maturity: Production 651 Coverage: All aspects of the protocol are implemented. 653 Licensing: GNU Lesser General Public License 655 Contact: jgould@verisign.com 657 URL: https://www.verisign.com/en_US/channel-resources/domain- 658 registry-products/epp-sdks 660 6.2. Neustar EPP SDK 662 Organisation: Neustar Inc. 664 Name: Neustar EPP SDK 665 Description: The Neustar EPP SDK includes a full client 666 implementation of draft-ietf-regext-allocation-token. 668 Level of maturity: Production 670 Coverage: All aspects of the protocol are implemented. 672 Licensing: GNU Lesser General Public License 674 Contact: quoc-anh.np@team.neustar 676 URL: http://registrytoolkit.neustar 678 6.3. Neustar gTLD SRS 680 Organisation: Neustar Inc. 682 Name: Neustar generic Top Level Domain (gTLD) Shared Registry System 683 (SRS). 685 Description: The Neustar gTLD SRS implements the server side of 686 draft-ietf-regext-allocation-token for several Top Level Domains. 688 Level of maturity: Production 690 Coverage: All server side aspects of the protocol are implemented. 692 Licensing: Proprietary 694 Contact: quoc-anh.np@team.neustar 696 6.4. Net::DRI 698 Organization: Dot and Co 700 Name: Net::DRI 702 Description: Net::DRI implements the client-side of draft-ietf- 703 regext-allocation-token. 705 Level of maturity: Production 707 Coverage: All client-side aspects of the protocol are implemented. 709 Licensing: GNU Lesser General Public License 711 Contact: netdri@dotandco.com 713 7. Security Considerations 715 The mapping described in this document does not provide any security 716 services beyond those described by EPP [RFC5730] and protocol layers 717 used by EPP. The security considerations described in these other 718 specifications apply to this specification as well. 720 The mapping acts as a conduit for the passing of Allocation Tokens 721 between a client and a server. The definition of the Allocation 722 Token is defined outside of this mapping. The following are security 723 considerations in the definition and use of an Allocation Token: 725 1. An Allocation Token should be considered secret information by 726 the client and should be protected at rest and in transit. 727 2. An Allocation Token should be single use, meaning it should be 728 unique per object and per allocation operation. 729 3. An Allocation Token should have a limited life with some form of 730 expiry in the Allocation Token if generated by a trusted 3rd 731 third party, or with a server-side expiry if generated by the 732 server. 733 4. An Allocation Token should use a strong random value if it is 734 based on an unsigned code. 735 5. An Allocation Token should leverage digital signatures to confirm 736 its authenticity if generated by a trusted 3rd party. 737 6. An Allocation Token should is signed XML should be encoded (e.g., 738 base64) to mitigate server validation issues. 740 8. Acknowledgements 742 The authors wish to acknowledge the original concept for this draft 743 and the efforts in the initial versions of this draft by Trung Tran 744 and Sharon Wodjenski. 746 Special suggestions that have been incorporated into this document 747 were provided by Scott Hollenbeck, Rubens Kuhl, Alexander Mayrhofer, 748 and Patrick Mevzek. 750 9. References 752 9.1. Normative References 754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 755 Requirement Levels", BCP 14, RFC 2119, 756 DOI 10.17487/RFC2119, March 1997, . 759 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 760 DOI 10.17487/RFC3688, January 2004, . 763 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 764 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 765 . 767 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 768 Domain Name Mapping", STD 69, RFC 5731, 769 DOI 10.17487/RFC5731, August 2009, . 772 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 773 Code: The Implementation Status Section", BCP 205, 774 RFC 7942, DOI 10.17487/RFC7942, July 2016, 775 . 777 9.2. Informative References 779 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 780 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 781 February 2015, . 783 Appendix A. Change History 785 A.1. Change from 00 to 01 787 1. Amended XML Namespace section of IANA Considerations, added EPP 788 Extension Registry section. 789 2. Moved Change History to the back section as an Appendix. 791 A.2. Change from 01 to 02 793 1. Ping update. 795 A.3. Change from 02 to 03 797 1. Ping update. 799 A.4. Change from 03 to 04 801 1. Updated the authors for the draft. 803 A.5. Change from 04 to REGEXT 00 805 1. Changed to regext working group draft by changing draft-gould- 806 allocation-token to draft-ietf-regext-allocation-token. 808 A.6. Change from REGEXT 00 to REGEXT 01 810 1. Ping update. 812 A.7. Change from REGEXT 01 to REGEXT 02 814 1. Added the Implementation Status section. 816 A.8. Change from REGEXT 02 to REGEXT 03 818 1. Changed Neustar author to Kal Feher. 820 A.9. Change from REGEXT 03 to REGEXT 04 822 1. Added Neustar implementation to the Implementation Status 823 section. 825 A.10. Change from REGEXT 04 to REGEXT 05 827 1. Updates based on feedback from Patrick Mevzek, that include: 829 1. Remove "or code" from the Abstract section. 830 2. Add a missing "to" in "an allocation token TO one of the 831 EPP..." in the Introduction section. 832 3. Reword the "The allocation token is known to the server..." 833 sentence in the Introduction section. 834 4. Modify the "The allocation token MAY be returned to an 835 authorized client for passing out-of-band to a client that 836 uses it with an EPP transform command" to clarify who the two 837 separate clients are. 838 5. Removed an unneeded ":" from the EPP Command and 839 EPP Command sections. 841 A.11. Change from REGEXT 05 to REGEXT 06 843 1. Fix description of Neustar gTLD SRS based on feedback from Rubens 844 Kuhl. 845 2. Updates based on feedback from Alexander Mayrhofer, that include: 847 1. Making all references to Allocation Token to use the upper 848 case form. 849 2. Revise the language of the abstract to include "for 850 including an Allocation Token in query and transform 851 commands. The Allocation Token is used as a credential that 852 authorizes a client to request the allocation of a specific 853 object from the server, using one of the EPP transform 854 commands..." 855 3. Replace the title "EPP Command" with "EPP 856 Query Command" for section 3.1.3. 857 4. Revise the second sentence of the Introduction to "The 858 mapping, ..., supports passing an Allocation Token..." 859 5. Change "support" to "require" in the Introduction sentence 860 "It is up to server policy which EPP transform commands and 861 which objects support the Allocation Token." 862 6. Add the definition of Allocation to the Introduction. 863 7. Removed "transform" from "all of the supported EPP transform 864 commands" in the "Allocation Token" section, since the 865 Allocation Token can be used with the "check" command as 866 well. 867 8. Remove the word "same" from "The same 868 element is used for 869 all..." in the "Allocation Token" section. 870 9. Change the description of the use of the 2201 error in the 871 "Allocation Token" section, the "EPP Command" 872 section, the "EPP Command" section, and the "EPP 873 Command" section. 874 10. Revise " to determine if an object is known to the 875 server..." to " to determine if an object can be 876 provisioned..." and remove "detailed" in the description of 877 the in the "EPP Query Commands" section. 878 11. Add missing description of the expected response 879 behavior. 880 12. Replaced the example reason "Invalid domain-token pair" with 881 "Allocation Token mismatch". 882 13. Replace "information on" with "information associated with" 883 in the "EPP Command" section. 884 14. Removed the "that identifies the extension namespace", the 885 ", defined in...", the Allocation Token links from the error 886 response sentences, and the "object referencing the 887 element" in the "EPP Command" 888 section. 889 15. Added "The authorization is subject to server policy." to 890 the "EPP Command" section. 891 16. Replace "or response>" with "or query 892 response>" in the EPP Query Command" section. 893 17. Replace "create an object" with "create an instance of an 894 object" in the "EPP Command" section. 895 18. Revised the sentence to include "the command MUST contain a 896 child element for the 897 client to be authorized to create and allocate the object" 898 in the "EPP Command" section. 900 19. Removed the reference to section 2.1 and the namespace 901 identification text in the "EPP Command" section. 902 20. Added "The authorization associated with the Allocation 903 Token is in addition to and does not replace the 904 authorization mechanism defined for the object's 905 request command." to the "EPP Command" section. 906 21. Modified the first sentence of the "EPP Extension Registry" 907 section to read "The following registration of the EPP 908 Extension Registry, described in RFC7451, is requested" 909 22. Removed support with using the Allocation Token with an 910 empty extension of update (e.g., release command), based on 911 the confusion and lack of known applicability. 912 3. Updates based on feedback from Scott Hollenbeck, that include: 914 1. Revised XML schema to included a minimum length of 1 for the 915 allocationTokenType. 916 2. Revised the "IANA Considerations" section to include the 917 registration of the XML schema. 918 3. Revised the "Security Considerations" section to include 919 considerations for the definition of the Allocation Tokens. 921 A.12. Change from REGEXT 06 to REGEXT 07 923 1. Updates based on feedback from Patrick Mevzek: 925 1. Updated obsoleted RFC 7942 to RFC 7942. 926 2. Moved RFC 7451 to an informational reference. 928 A.13. Change from REGEXT 07 to REGEXT 08 930 1. Changed Kal Feher's contact e-mail address. 931 2. Changed Neustar's Implementation Status contact e-mail address. 932 3. Added the Net::DRI sub-section to the Implementation Status 933 section. 935 Authors' Addresses 937 James Gould 938 VeriSign, Inc. 939 12061 Bluemont Way 940 Reston, VA 20190 941 US 943 Email: jgould@verisign.com 944 URI: http://www.verisigninc.com 945 Kal Feher 946 Neustar 947 lvl 8/10 Queens Road 948 Melbourne, VIC 3004 949 AU 951 Email: ietf@feherfamily.org 952 URI: http://www.neustar.biz