idnits 2.17.1 draft-ietf-regext-allocation-token-01.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 (April 17, 2017) is 2565 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) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 1 error (**), 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 S. Wodjenski 5 Expires: October 19, 2017 Neustar 6 April 17, 2017 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-01 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 October 19, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 78 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 17 79 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 17 80 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 17 81 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 17 82 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 17 83 A.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 17 84 A.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 This document describes an extension mapping for version 1.0 of the 90 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 91 extension to EPP object mappings like the EPP domain name mapping 92 [RFC5731], for passing an allocation token one of the EPP transform 93 commands including create, update, and transfer. The allocation 94 token is known to the server to authorize a client that passes a 95 matching allocation token with one of the supported EPP transform 96 commands. It is up to server policy which EPP transform commands and 97 which objects support the allocation token. The allocation token MAY 98 be returned to an authorized client for passing out-of-band to a 99 client that uses it with an EPP transform command. 101 1.1. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 XML is case sensitive. Unless stated otherwise, XML specifications 108 and examples provided in this document MUST be interpreted in the 109 character case presented in order to develop a conforming 110 implementation. 112 In examples, "C:" represents lines sent by a protocol client and "S:" 113 represents lines returned by a protocol server. Indentation and 114 white space in examples are provided only to illustrate element 115 relationships and are not a REQUIRED feature of this protocol. 117 "allocationToken-1.0" is used as an abbreviation for 118 "urn:ietf:params:xml:ns:allocationToken-1.0". The XML namespace 119 prefix "allocationToken" is used, but implementations MUST NOT depend 120 on it and instead employ a proper namespace-aware XML parser and 121 serializer to interpret and output the XML documents. 123 2. Object Attributes 125 This extension adds additional elements to EPP object mappings like 126 the EPP domain name mapping [RFC5731]. Only those new elements are 127 described here. 129 2.1. Allocation Token 131 The Allocation Token is a simple XML "token" type. The exact format 132 of the Allocation Token is up to server policy. The server MUST have 133 the allocation token for each object to match against the allocation 134 token passed by the client to authorize the allocation of the object. 135 The same element is used for all of 136 the supported EPP transform commands as well as the info response. 137 If an invalid allocation token is passed the server MUST return an 138 EPP error result code of 2201. 140 An example element with value of 141 "abc123": 143 145 abc123 146 148 3. EPP Command Mapping 150 A detailed description of the EPP syntax and semantics can be found 151 in the EPP core protocol specification [RFC5730]. 153 3.1. EPP Query Commands 155 EPP provides three commands to retrieve object information: 156 to determine if an object is known to the server, to retrieve 157 detailed information associated with an object, and to 158 retrieve object transfer status information. 160 3.1.1. EPP Command 162 This extension defines additional elements to extend the EPP 163 command of an object mapping like [RFC5731]. 165 This extension allow clients to check the availability of an object 166 with an allocation token, as described in Section 2.1. Clients can 167 check if an object can be created using the allocation token. The 168 allocation token is applied to all object names included in the EPP 169 command. 171 Example command for the example.tld domain name using the 172 extension with the allocation token 173 of 'abc123': 175 C: 176 C: 177 C: 178 C: 179 C: 181 C: example.tld 182 C: 183 C: 184 C: 185 C: 188 C: abc123 189 C: 190 C: 191 C: ABC-12345 192 C: 193 C: 195 If the query was successful, the server replies with an 196 response providing availability status of queried object. 198 Example domain response for a command using the 199 extension: 201 S: 202 S: 203 S: 204 S: 205 S: Command completed successfully 206 S: 207 S: 208 S: 210 S: 211 S: example.tld 212 S: Invalid domain-token pair 213 S: 214 S: 215 S: 216 S: 217 S: ABC-DEF-12345 218 S: 54321-XYZ 219 S: 220 S: 221 S: 222 Example command with the 223 extension for the example.tld and example2.tld domain names. 224 Availability of example.tld and example2.tld domain names are based 225 on the allocation token 'abc123': 227 C: 228 C: 229 C: 230 C: 231 C: 233 C: example.tld 234 C: example2.tld 235 C: 236 C: 237 C: 238 C: 241 C: abc123 242 C: 243 C: 244 C: ABC-DEF-12345 245 C: 246 C: 247 Example domain response for multiple domain names in the 248 command using the 249 extension: 251 S: 252 S: 253 S: 254 S: 255 S: Command completed successfully 256 S: 257 S: 258 S: 260 S: 261 S: example.tld 262 S: Invalid domain-token pair 263 S: 264 S: 265 S: example2.tld 266 S: 267 S: 268 S: 269 S: 270 S: ABC-DEF-12345 271 S: 54321-XYZ 272 S: 273 S: 274 S: 276 This extension does not add any elements to the EPP response 277 described in the [RFC5730]. 279 3.1.2. EPP Command 281 This extension defines additional elements to extend the EPP 282 command of an object mapping like [RFC5731]. 284 The EPP command allows a client to request information on an 285 existing object. Authorized clients MAY retrieve the allocation 286 token (Section 2.1) along with the other object information using the 287 element that identifies the extension 288 namespace. The element is an empty element 289 that serves as a marker to the server to return the 290 element, defined in Section 2.1, in 291 the info response. If the client is not authorized to receive the 292 allocation token (Section 2.1), the server MUST return an EPP error 293 result code of 2201. If the client is authorized to receive the 294 allocation token (Section 2.1), but there is no allocation token 295 (Section 2.1) associated with the object, the server MUST return an 296 EPP error result code of 2303 object referencing the 297 element. 299 Example command with the allocationToken:info extension for 300 the example.tld domain name: 302 C: 303 C: 304 C: 305 C: 306 C: 310 C: example.tld 311 C: 312 C: 313 C: 314 C: 317 C: 318 C: ABC-12345 319 C: 320 C: 322 If the query was successful, the server replies with an 323 element, as described in 324 Section 2.1. 326 Example domain response using the 327 extension: 329 S: 330 S: 331 S: 332 S: 333 S: Command completed successfully 334 S: 335 S: 336 S: 338 S: example.tld 339 S: EXAMPLE1-REP 340 S: 341 S: jd1234 342 S: sh8013 343 S: sh8013 344 S: ClientX 345 S: ClientY 346 S: 2012-04-03T22:00:00.0Z 347 S: 348 S: 2fooBAR 349 S: 350 S: 351 S: 352 S: 353 S: 356 S: abc123 357 S: 358 S: 359 S: 360 S: ABC-12345 361 S: 54321-XYZ 362 S: 363 S: 364 S: 366 3.1.3. EPP Command 368 This extension does not add any elements to the EPP query 369 command or response described in the [RFC5730]. 371 3.2. EPP Transform Commands 373 EPP provides five commands to transform objects: to create 374 an instance of an object, to delete an instance of an 375 object, to extend the validity period of an object, 376 to manage object sponsorship changes, and to 377 change information associated with an object. 379 3.2.1. EPP Command 381 This extension defines additional elements to extend the EPP 382 command of an object mapping like [RFC5731]. 384 The EPP command provides a transform operation that allows a 385 client to create an object. In addition to the EPP command elements 386 described in an object mapping like [RFC5731], the command MUST 387 contain a child element, as defined 388 in Section 2.1, that identifies the extension namespace for the 389 client to be authorized to create and allocate the object. If the 390 allocation token (Section 2.1) does not match the object's allocation 391 token (Section 2.1), the server MUST return an EPP error result code 392 of 2201.: 394 Example command to create a domain object with an allocation 395 token: 397 C: 398 C: 399 C: 400 C: 401 C: 403 C: example.tld 404 C: jd1234 405 C: sh8013 406 C: sh8013 407 C: 408 C: 2fooBAR 409 C: 410 C: 411 C: 412 C: 413 C: 416 C: abc123 417 C: 418 C: 419 C: ABC-12345 420 C: 421 C: 423 This extension does not add any elements to the EPP response 424 described in the [RFC5730]. 426 3.2.2. EPP Command 428 This extension does not add any elements to the EPP command 429 or response described in the [RFC5730]. 431 3.2.3. EPP Command 433 This extension does not add any elements to the EPP command 434 or response described in the [RFC5730]. 436 3.2.4. EPP Command 438 This extension defines additional elements to extend the EPP 439 request command of an object mapping like [RFC5731]. 441 The EPP request command provides a transform operation 442 that allows a client to request the transfer of an object. In 443 addition to the EPP command elements described in an object mapping 444 like [RFC5731], the command MUST contain a child 445 element, as defined in Section 2.1, 446 that identifies the extension namespace for the client to be 447 authorized to transfer and allocate the object. If the allocation 448 token (Section 2.1) does not match the object's allocation token 449 (Section 2.1), the server MUST return an EPP error result code of 450 2201.: 452 Example request command to allocate the domain object with 453 the allocation token: 455 C: 456 C: 457 C: 458 C: 459 C: 461 C: example1.tld 462 C: 1 463 C: 464 C: 2fooBAR 465 C: 466 C: 467 C: 468 C: 469 C: 472 C: abc123 473 C: 474 C: 475 C: ABC-12345 476 C: 477 C: 479 This extension does not add any elements to the EPP 480 response described in the [RFC5730]. 482 3.2.5. EPP Command 484 This extension defines additional elements to extend an extension of 485 an empty EPP command of an object mapping like [RFC5731]. 486 An example of an extension of an empty EPP command is the 487 definition of the restore command within [RFC3915]. 489 An extension of an empty EPP command defines a new verb that 490 transforms an object. In addition to the EPP command elements 491 described in an object mapping like [RFC5731], the command MUST 492 contain a child element, as defined 493 in Section 2.1, that identifies the extension namespace for the 494 client to be authorized to allocate the object. If the allocation 495 token (Section 2.1) does not match the object's allocation token 496 (Section 2.1), the server MUST return an EPP error result code of 497 2201.: 499 Example use an extension of an empty command to release a 500 domain object with an allocation token: 502 C: 503 C: 504 C: 505 C: 506 C: 508 C: example1.tld 509 C: 510 C: 511 C: 512 C: 514 C: 517 C: abc123 518 C: 519 C: 520 C: ABC-12345-XYZ 521 C: 522 C: 524 This extension does not add any elements to the EPP response 525 described in the [RFC5730]. 527 4. Formal Syntax 529 One schema is presented here that is the EPP Allocation Token 530 Extension schema. 532 The formal syntax presented here is a complete schema representation 533 of the object mapping suitable for automated validation of EPP XML 534 instances. The BEGIN and END tags are not part of the schema; they 535 are used to note the beginning and ending of the schema for URI 536 registration purposes. 538 4.1. Allocation Token Extension Schema 540 BEGIN 541 543 548 549 550 Extensible Provisioning Protocol v1.0 551 Allocation Token Extension. 552 553 555 556 558 560 563 564 565 566 567 569 570 571 END 573 5. IANA Considerations 575 5.1. XML Namespace 577 This document uses URNs to describe XML namespaces and XML schemas 578 conforming to a registry mechanism described in [RFC3688]. The 579 following URI assignment is requested of IANA: 581 URI: ietf:params:xml:ns:allocationToken-1.0 583 Registrant Contact: See the "Author's Address" section of this 584 document. 586 XML: See the "Formal Syntax" section of this document. 588 5.2. EPP Extension Registry 590 The EPP extension described in this document should be registered by 591 the IANA in the EPP Extension Registry described in [RFC7451]. The 592 details of the registration are as follows: 594 Name of Extension: "Allocation Token Extension for the Extensible 595 Provisioning Protocol (EPP)" 597 Document status: Standards Track 599 Reference: (insert reference to RFC version of this document) 601 Registrant Name and Email Address: IESG, 603 TLDs: Any 605 IPR Disclosure: None 607 Status: Active 609 Notes: None 611 6. Security Considerations 613 The mapping extensions described in this document do not provide any 614 security services beyond those described by EPP [RFC5730] and 615 protocol layers used by EPP. The security considerations described 616 in these other specifications apply to this specification as well. 618 7. Acknowledgements 620 The authors wish to acknowledge the original concept for this draft 621 and the efforts in the initial versions of this draft by Trung Tran. 623 8. Normative References 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 631 DOI 10.17487/RFC3688, January 2004, 632 . 634 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 635 the Extensible Provisioning Protocol (EPP)", RFC 3915, 636 DOI 10.17487/RFC3915, September 2004, 637 . 639 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 640 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 641 . 643 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 644 Domain Name Mapping", STD 69, RFC 5731, 645 DOI 10.17487/RFC5731, August 2009, 646 . 648 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 649 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 650 February 2015, . 652 Appendix A. Change History 654 A.1. Change from 00 to 01 656 1. Amended XML Namespace section of IANA Considerations, added EPP 657 Extension Registry section. 658 2. Moved Change History to the back section as an Appendix. 660 A.2. Change from 01 to 02 662 1. Ping update. 664 A.3. Change from 02 to 03 666 1. Ping update. 668 A.4. Change from 03 to 04 670 1. Updated the authors for the draft. 672 A.5. Change from 04 to REGEXT 00 674 1. Changed to regext working group draft by changing draft-gould- 675 allocation-token to draft-ietf-regext-allocation-token. 677 A.6. Change from REGEXT 00 to REGEXT 01 679 1. Ping update. 681 Authors' Addresses 683 James Gould 684 VeriSign, Inc. 685 12061 Bluemont Way 686 Reston, VA 20190 687 US 689 Email: jgould@verisign.com 690 URI: http://www.verisigninc.com 692 Sharon Wodjenski 693 Neustar 694 21575 Ridgetop Circle 695 Sterling, VA 20166 696 US 698 Email: Sharon.Wodjenski@neustar.biz 699 URI: http://www.neustar.biz