idnits 2.17.1 draft-ietf-regext-allocation-token-06.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 (January 29, 2018) is 2279 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: August 2, 2018 Neustar 6 January 29, 2018 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-06 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 August 2, 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 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . 19 91 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 19 92 A.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 20 93 A.11. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 This document describes an extension mapping for version 1.0 of the 99 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 100 extension to EPP object mappings like the EPP domain name mapping 101 [RFC5731], supports passing an Allocation Token as a credential that 102 authorizes a client to request the allocation of a specific object 103 from the server, using one of the EPP transform commands including 104 create and transfer. 106 Allocation is when a server assigns the sponsoring client of an 107 object based on the use of an Allocation Token credential. Examples 108 include allocating a registration based on a pre-eligibility 109 Allocation Token, allocating a premium domain name registration based 110 on an auction Allocation Token, allocating a registration based on a 111 founders Allocation Token, and allocating an existing domain name 112 held by the server or by a different sponsoring client based on an 113 Allocation Token passed with a transfer command. 115 A client MUST pass an Allocation Token known to the server to be 116 authorized to use one of the supported EPP transform commands. It is 117 up to server policy which EPP transform commands and which objects 118 require the Allocation Token. The Allocation Token MAY be returned 119 to an authorized client for passing out-of-band to a client that uses 120 it with an EPP transform command. 122 1.1. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 XML is case sensitive. Unless stated otherwise, XML specifications 129 and examples provided in this document MUST be interpreted in the 130 character case presented in order to develop a conforming 131 implementation. 133 In examples, "C:" represents lines sent by a protocol client and "S:" 134 represents lines returned by a protocol server. Indentation and 135 white space in examples are provided only to illustrate element 136 relationships and are not a REQUIRED feature of this protocol. 138 "allocationToken-1.0" is used as an abbreviation for 139 "urn:ietf:params:xml:ns:allocationToken-1.0". The XML namespace 140 prefix "allocationToken" is used, but implementations MUST NOT depend 141 on it and instead employ a proper namespace-aware XML parser and 142 serializer to interpret and output the XML documents. 144 2. Object Attributes 146 This extension adds additional elements to EPP object mappings like 147 the EPP domain name mapping [RFC5731]. Only those new elements are 148 described here. 150 2.1. Allocation Token 152 The Allocation Token is a simple XML "token" type. The exact format 153 of the Allocation Token is up to server policy. The server MUST have 154 the Allocation Token for each object to match against the Allocation 155 Token passed by the client to authorize the allocation of the object. 156 The element is used for all of the 157 supported EPP commands as well as the info response. If the 158 Allocation Token passed to the server does not apply to the object, 159 the server MUST return an EPP error result code of 2201. 161 An example element with value of 162 "abc123": 164 166 abc123 167 169 3. EPP Command Mapping 171 A detailed description of the EPP syntax and semantics can be found 172 in the EPP core protocol specification [RFC5730]. 174 3.1. EPP Query Commands 176 EPP provides three commands to retrieve object information: 177 to determine if an object can be provisioned, to retrieve 178 information associated with an object, and to retrieve 179 object transfer status information. 181 3.1.1. EPP Command 183 This extension defines additional elements to extend the EPP 184 command of an object mapping like [RFC5731]. 186 This extension allow clients to check the availability of an object 187 with an Allocation Token, as described in Section 2.1. Clients can 188 check if an object can be created using the Allocation Token. The 189 Allocation Token is applied to all object names included in the EPP 190 command. 192 Example command for the example.tld domain name using the 193 extension with the allocation token 194 of 'abc123': 196 C: 197 C: 198 C: 199 C: 200 C: 202 C: example.tld 203 C: 204 C: 205 C: 206 C: 209 C: abc123 210 C: 211 C: 212 C: ABC-12345 213 C: 214 C: 216 If the query was successful, the server replies with a 217 response providing the availability status of the queried object 218 based on the following Allocation Token cases, where the object is 219 otherwise available: 221 1. If an object requires an Allocation Token and the Allocation 222 Token does apply to the object, then the server MUST return the 223 availability status as available (e.g., "avail" attribute is "1" 224 or "true"). 225 2. If an object requires an Allocation Token and the Allocation 226 Token does not apply to the object or an object does not require 227 an Allocation Token, then the server SHOULD return the 228 availability status as unavailable (e.g., "avail" attribute is 229 "0" or "false"). 231 Example domain response for a command using the 232 extension: 234 S: 235 S: 236 S: 237 S: 238 S: Command completed successfully 239 S: 240 S: 241 S: 243 S: 244 S: example.tld 245 S: Allocation Token mismatch 246 S: 247 S: 248 S: 249 S: 250 S: ABC-DEF-12345 251 S: 54321-XYZ 252 S: 253 S: 254 S: 255 Example command with the 256 extension for the example.tld and example2.tld domain names. 257 Availability of example.tld and example2.tld domain names are based 258 on the Allocation Token 'abc123': 260 C: 261 C: 262 C: 263 C: 264 C: 266 C: example.tld 267 C: example2.tld 268 C: 269 C: 270 C: 271 C: 274 C: abc123 275 C: 276 C: 277 C: ABC-DEF-12345 278 C: 279 C: 280 Example domain response for multiple domain names in the 281 command using the 282 extension: 284 S: 285 S: 286 S: 287 S: 288 S: Command completed successfully 289 S: 290 S: 291 S: 293 S: 294 S: example.tld 295 S: Allocation Token mismatch 296 S: 297 S: 298 S: example2.tld 299 S: 300 S: 301 S: 302 S: 303 S: ABC-DEF-12345 304 S: 54321-XYZ 305 S: 306 S: 307 S: 309 This extension does not add any elements to the EPP response 310 described in the [RFC5730]. 312 3.1.2. EPP Command 314 This extension defines additional elements to extend the EPP 315 command of an object mapping like [RFC5731]. 317 The EPP command allows a client to request information 318 associated with an existing object. Authorized clients MAY retrieve 319 the Allocation Token (Section 2.1) along with the other object 320 information using the element. The 321 element is an empty element that serves as a 322 marker to the server to return the 323 element in the info response. If the client is not authorized to 324 receive the Allocation Token, the server MUST return an EPP error 325 result code of 2201. If the client is authorized to receive the 326 Allocation Token, but there is no Allocation Token associated with 327 the object, the server MUST return an EPP error result code of 2303 328 object referencing the element. The 329 auhorization is subject to server policy. 331 Example command with the allocationToken:info extension for 332 the example.tld domain name: 334 C: 335 C: 336 C: 337 C: 338 C: 342 C: example.tld 343 C: 344 C: 345 C: 346 C: 349 C: 350 C: ABC-12345 351 C: 352 C: 354 If the query was successful, the server replies with an 355 element, as described in 356 Section 2.1. 358 Example domain response using the 359 extension: 361 S: 362 S: 363 S: 364 S: 365 S: Command completed successfully 366 S: 367 S: 368 S: 370 S: example.tld 371 S: EXAMPLE1-REP 372 S: 373 S: jd1234 374 S: sh8013 375 S: sh8013 376 S: ClientX 377 S: ClientY 378 S: 2012-04-03T22:00:00.0Z 379 S: 380 S: 2fooBAR 381 S: 382 S: 383 S: 384 S: 385 S: 388 S: abc123 389 S: 390 S: 391 S: 392 S: ABC-12345 393 S: 54321-XYZ 394 S: 395 S: 396 S: 398 3.1.3. EPP Query Command 400 This extension does not add any elements to the EPP query 401 command or query response described in the [RFC5730]. 403 3.2. EPP Transform Commands 405 EPP provides five commands to transform objects: to create 406 an instance of an object, to delete an instance of an 407 object, to extend the validity period of an object, 408 to manage object sponsorship changes, and to 409 change information associated with an object. 411 3.2.1. EPP Command 413 This extension defines additional elements to extend the EPP 414 command of an object mapping like [RFC5731]. 416 The EPP command provides a transform operation that allows a 417 client to create an instance of an object. In addition to the EPP 418 command elements described in an object mapping like [RFC5731], the 419 command MUST contain a child 420 element for the client to be authorized to create and allocate the 421 object. If the Allocation Token does not apply to the object, the 422 server MUST return an EPP error result code of 2201. 424 Example command to create a domain object with an Allocation 425 Token: 427 C: 428 C: 429 C: 430 C: 431 C: 433 C: example.tld 434 C: jd1234 435 C: sh8013 436 C: sh8013 437 C: 438 C: 2fooBAR 439 C: 440 C: 441 C: 442 C: 443 C: 446 C: abc123 447 C: 448 C: 449 C: ABC-12345 450 C: 451 C: 453 This extension does not add any elements to the EPP response 454 described in the [RFC5730]. 456 3.2.2. EPP Command 458 This extension does not add any elements to the EPP command 459 or response described in the [RFC5730]. 461 3.2.3. EPP Command 463 This extension does not add any elements to the EPP command 464 or response described in the [RFC5730]. 466 3.2.4. EPP Command 468 This extension defines additional elements to extend the EPP 469 request command of an object mapping like [RFC5731]. 471 The EPP request command provides a transform operation 472 that allows a client to request the transfer of an object. In 473 addition to the EPP command elements described in an object mapping 474 like [RFC5731], the command MUST contain a child 475 element for the client to be 476 authorized to transfer and allocate the object. The authorization 477 associated with the Allocation Token is in addition to and does not 478 replace the authorization mechanism defined for the object's 479 request command. If the Allocation Token does not apply 480 to the object, the server MUST return an EPP error result code of 481 2201. 483 Example request command to allocate the domain object with 484 the Allocation Token: 486 C: 487 C: 488 C: 489 C: 490 C: 492 C: example1.tld 493 C: 1 494 C: 495 C: 2fooBAR 496 C: 497 C: 498 C: 499 C: 500 C: 503 C: abc123 504 C: 505 C: 506 C: ABC-12345 507 C: 508 C: 510 This extension does not add any elements to the EPP 511 response described in the [RFC5730]. 513 3.2.5. EPP Command 515 This extension does not add any elements to the EPP command 516 or response described in the [RFC5730]. 518 4. Formal Syntax 520 One schema is presented here that is the EPP Allocation Token 521 Extension schema. 523 The formal syntax presented here is a complete schema representation 524 of the object mapping suitable for automated validation of EPP XML 525 instances. The BEGIN and END tags are not part of the schema; they 526 are used to note the beginning and ending of the schema for URI 527 registration purposes. 529 4.1. Allocation Token Extension Schema 531 BEGIN 532 533 540 541 542 Extensible Provisioning Protocol v1.0 543 Allocation 544 Token Extension. 545 546 548 549 551 553 557 558 559 560 561 563 564 565 END 567 5. IANA Considerations 569 5.1. XML Namespace 571 This document uses URNs to describe XML namespaces and XML schemas 572 conforming to a registry mechanism described in [RFC3688]. The 573 following URI assignment is requested of IANA: 575 Registration request for the allocationToken namespace: 577 URI: ietf:params:xml:ns:allocationToken-1.0 578 Registrant Contact: IESG 579 XML: None. Namespace URIs do not represent an XML specification. 581 Registration request for the allocationToken XML schema: 583 URI: ietf:params:xml:ns:allocationToken-1.0 584 Registrant Contact: IESG 585 XML: See the "Formal Syntax" section of this document. 587 5.2. EPP Extension Registry 589 The following registration of the EPP Extension Registry, described 590 in [RFC7451], is requested: 592 Name of Extension: "Allocation Token Extension for the Extensible 593 Provisioning Protocol (EPP)" 595 Document status: Standards Track 597 Reference: (insert reference to RFC version of this document) 599 Registrant Name and Email Address: IESG, 601 TLDs: Any 603 IPR Disclosure: None 605 Status: Active 607 Notes: None 609 6. Implementation Status 611 Note to RFC Editor: Please remove this section and the reference to 612 RFC 6982 [RFC6982] before publication. 614 This section records the status of known implementations of the 615 protocol defined by this specification at the time of posting of this 616 Internet-Draft, and is based on a proposal described in RFC 6982 617 [RFC6982]. The description of implementations in this section is 618 intended to assist the IETF in its decision processes in progressing 619 drafts to RFCs. Please note that the listing of any individual 620 implementation here does not imply endorsement by the IETF. 621 Furthermore, no effort has been spent to verify the information 622 presented here that was supplied by IETF contributors. This is not 623 intended as, and must not be construed to be, a catalog of available 624 implementations or their features. Readers are advised to note that 625 other implementations may exist. 627 According to RFC 6982 [RFC6982], "this will allow reviewers and 628 working groups to assign due consideration to documents that have the 629 benefit of running code, which may serve as evidence of valuable 630 experimentation and feedback that have made the implemented protocols 631 more mature. It is up to the individual working groups to use this 632 information as they see fit". 634 6.1. Verisign EPP SDK 636 Organization: Verisign Inc. 638 Name: Verisign EPP SDK 640 Description: The Verisign EPP SDK includes both a full client 641 implementation and a full server stub implementation of draft-ietf- 642 regext-allocation-token. 644 Level of maturity: Production 646 Coverage: All aspects of the protocol are implemented. 648 Licensing: GNU Lesser General Public License 650 Contact: jgould@verisign.com 652 URL: https://www.verisign.com/en_US/channel-resources/domain- 653 registry-products/epp-sdks 655 6.2. Neustar EPP SDK 657 Organisation: Neustar Inc. 659 Name: Neustar EPP SDK 660 Description: The Neustar EPP SDK includes a full client 661 implementation of draft-ietf-regext-allocation-token. 663 Level of maturity: Production 665 Coverage: All aspects of the protocol are implemented. 667 Licensing: GNU Lesser General Public License 669 Contact: kal.feher@team.neustar 671 URL: http://registrytoolkit.neustar 673 6.3. Neustar gTLD SRS 675 Organisation: Neustar Inc. 677 Name: Neustar generic Top Level Domain (gTLD) Shared Registry System 678 (SRS). 680 Description: The Neustar gTLD SRS implements the server side of 681 draft-ietf-regext-allocation-token for several Top Level Domains. 683 Level of maturity: Production 685 Coverage: All server side aspects of the protocol are implemented. 687 Licensing: Proprietary 689 Contact: kal.feher@team.neustar 691 7. Security Considerations 693 The mapping described in this document does not provide any security 694 services beyond those described by EPP [RFC5730] and protocol layers 695 used by EPP. The security considerations described in these other 696 specifications apply to this specification as well. 698 The mapping acts as a conduit for the passing of Allocation Tokens 699 between a client and a server. The definition of the Allocation 700 Token is defined outside of this mapping. The following are security 701 considerations in the definition and use of an Allocation Token: 703 1. An Allocation Token should be considered secret information by 704 the client and should be protected at rest and in transit. 705 2. An Allocation Token should be single use, meaning it should be 706 unique per object and per allocation operation. 708 3. An Allocation Token should have a limited life with some form of 709 expiry in the Allocation Token if generated by a trusted 3rd 710 third party, or with a server-side expiry if generated by the 711 server. 712 4. An Allocation Token should use a strong random value if it is 713 based on an unsigned code. 714 5. An Allocation Token should leverage digital signatures to confirm 715 its authenticity if generated by a trusted 3rd party. 716 6. An Allocation Token should is signed XML should be encoded (e.g., 717 base64) to mitigate server validation issues. 719 8. Acknowledgements 721 The authors wish to acknowledge the original concept for this draft 722 and the efforts in the initial versions of this draft by Trung Tran 723 and Sharon Wodjenski. 725 Special suggestions that have been incorporated into this document 726 were provided by Scott Hollenbeck, Rubens Kuhl, Alexander Mayrhofer, 727 and Patrick Mevzek. 729 9. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, . 736 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 737 DOI 10.17487/RFC3688, January 2004, . 740 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 741 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 742 . 744 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 745 Domain Name Mapping", STD 69, RFC 5731, 746 DOI 10.17487/RFC5731, August 2009, . 749 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 750 Code: The Implementation Status Section", RFC 6982, 751 DOI 10.17487/RFC6982, July 2013, . 754 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 755 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 756 February 2015, . 758 Appendix A. Change History 760 A.1. Change from 00 to 01 762 1. Amended XML Namespace section of IANA Considerations, added EPP 763 Extension Registry section. 764 2. Moved Change History to the back section as an Appendix. 766 A.2. Change from 01 to 02 768 1. Ping update. 770 A.3. Change from 02 to 03 772 1. Ping update. 774 A.4. Change from 03 to 04 776 1. Updated the authors for the draft. 778 A.5. Change from 04 to REGEXT 00 780 1. Changed to regext working group draft by changing draft-gould- 781 allocation-token to draft-ietf-regext-allocation-token. 783 A.6. Change from REGEXT 00 to REGEXT 01 785 1. Ping update. 787 A.7. Change from REGEXT 01 to REGEXT 02 789 1. Added the Implementation Status section. 791 A.8. Change from REGEXT 02 to REGEXT 03 793 1. Changed Neustar author to Kal Feher. 795 A.9. Change from REGEXT 03 to REGEXT 04 797 1. Added Neustar implementation to the Implementation Status 798 section. 800 A.10. Change from REGEXT 04 to REGEXT 05 802 1. Updates based on feedback from Patrick Mevzek, that include: 804 1. Remove "or code" from the Abstract section. 805 2. Add a missing "to" in "an allocation token TO one of the 806 EPP..." in the Introduction section. 807 3. Reword the "The allocation token is known to the server..." 808 sentence in the Introduction section. 809 4. Modify the "The allocation token MAY be returned to an 810 authorized client for passing out-of-band to a client that 811 uses it with an EPP transform command" to clarify who the two 812 separate clients are. 813 5. Removed an unneeded ":" from the EPP Command and 814 EPP Command sections. 816 A.11. Change from REGEXT 05 to REGEXT 06 818 1. Fix description of Neustar gTLD SRS based on feedback from Rubens 819 Kuhl. 820 2. Updates based on feedback from Alexander Mayrhofer, that include: 822 1. Making all references to Allocation Token to use the upper 823 case form. 824 2. Revise the language of the abstract to include "for 825 including an Allocation Token in query and transform 826 commands. The Allocation Token is used as a credential that 827 authorizes a client to request the allocation of a specific 828 object from the server, using one of the EPP transform 829 commands..." 830 3. Replace the title "EPP Command" with "EPP 831 Query Command" for section 3.1.3. 832 4. Revise the second sentence of the Introduction to "The 833 mapping, ..., supports passing an Allocation Token..." 834 5. Change "support" to "require" in the Introduction sentence 835 "It is up to server policy which EPP transform commands and 836 which objects support the Allocation Token." 837 6. Add the definition of Allocation to the Introduction. 838 7. Removed "transform" from "all of the supported EPP transform 839 commands" in the "Allocation Token" section, since the 840 Allocation Token can be used with the "check" command as 841 well. 842 8. Remove the word "same" from "The same 843 element is used for 844 all..." in the "Allocation Token" section. 845 9. Change the description of the use of the 2201 error in the 846 "Allocation Token" section, the "EPP Command" 847 section, the "EPP Command" section, and the "EPP 848 Command" section. 849 10. Revise " to determine if an object is known to the 850 server..." to " to determine if an object can be 851 provisioned..." and remove "detailed" in the description of 852 the in the "EPP Query Commands" section. 853 11. Add missing description of the expected response 854 behavior. 855 12. Replaced the example reason "Invalid domain-token pair" with 856 "Allocation Token mismatch". 857 13. Replace "information on" with "information associated with" 858 in the "EPP Command" section. 859 14. Removed the "that identifies the extension namespace", the 860 ", defined in...", the Allocation Token links from the error 861 response sentences, and the "object referencing the 862 element" in the "EPP Command" 863 section. 864 15. Added "The authorization is subject to server policy." to 865 the "EPP Command" section. 866 16. Replace "or response>" with "or query 867 response>" in the EPP Query Command" section. 868 17. Replace "create an object" with "create an instance of an 869 object" in the "EPP Command" section. 870 18. Revised the sentence to include "the command MUST contain a 871 child element for the 872 client to be authorized to create and allocate the object" 873 in the "EPP Command" section. 874 19. Removed the reference to section 2.1 and the namespace 875 identification text in the "EPP Command" section. 876 20. Added "The authorization associated with the Allocation 877 Token is in addition to and does not replace the 878 authorization mechanism defined for the object's 879 request command." to the "EPP Command" section. 880 21. Modified the first sentence of the "EPP Extension Registry" 881 section to read "The following registration of the EPP 882 Extension Registry, described in RFC7451, is requested" 883 22. Removed support with using the Allocation Token with an 884 empty extension of update (e.g., release command), based on 885 the confusion and lack of known applicability. 886 3. Updates based on feedback from Scott Hollenbeck, that include: 888 1. Revised XML schema to included a minimum length of 1 for the 889 allocationTokenType. 890 2. Revised the "IANA Considerations" section to include the 891 registration of the XML schema. 892 3. Revised the "Security Considerations" section to include 893 considerations for the definition of the Allocation Tokens. 895 Authors' Addresses 897 James Gould 898 VeriSign, Inc. 899 12061 Bluemont Way 900 Reston, VA 20190 901 US 903 Email: jgould@verisign.com 904 URI: http://www.verisigninc.com 906 Kal Feher 907 Neustar 908 lvl 8/10 Queens Road 909 Melbourne, VIC 3004 910 AU 912 Email: kal.feher@team.neustar 913 URI: http://www.neustar.biz