--- 1/draft-ietf-regext-allocation-token-11.txt 2018-10-03 08:13:40.629000636 -0700 +++ 2/draft-ietf-regext-allocation-token-12.txt 2018-10-03 08:13:40.677001795 -0700 @@ -1,55 +1,55 @@ Network Working Group J. Gould Internet-Draft VeriSign, Inc. Intended status: Standards Track K. Feher -Expires: March 8, 2019 Neustar - September 4, 2018 +Expires: April 7, 2019 Neustar + October 04, 2018 Allocation Token Extension for the Extensible Provisioning Protocol (EPP) - draft-ietf-regext-allocation-token-11 + draft-ietf-regext-allocation-token-12 Abstract This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server, using one of the EPP transform commands including create and transfer. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 8, 2019. + This Internet-Draft will expire on April 7, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -92,20 +92,21 @@ A.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 21 A.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 21 A.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 21 A.11. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 22 A.12. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 23 A.13. Change from REGEXT 07 to REGEXT 08 . . . . . . . . . . . 23 A.14. Change from REGEXT 08 to REGEXT 09 . . . . . . . . . . . 24 A.15. Change from REGEXT 09 to REGEXT 10 . . . . . . . . . . . 24 A.16. Change from REGEXT 10 to REGEXT 11 . . . . . . . . . . . 25 + A.17. Change from REGEXT 11 to REGEXT 12 . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an extension to EPP object mappings like the EPP domain name mapping [RFC5731], supports passing an Allocation Token as a credential that authorizes a client to request the allocation of a specific object from the server, using one of the EPP transform commands including @@ -246,43 +247,41 @@ If the query was successful, the server replies with a response providing the availability status of the queried object based on the following Allocation Token cases, where the object is otherwise available: 1. If an object requires an Allocation Token and the Allocation Token does apply to the object, then the server MUST return the availability status as available (e.g., "avail" attribute is "1" or "true"). 2. If an object requires an Allocation Token and the Allocation - Token does not apply to the object or an object does not require - an Allocation Token, then the server SHOULD return the - availability status as unavailable (e.g., "avail" attribute is - "0" or "false"). + Token does not apply to the object, then the server SHOULD return + the availability status as unavailable (e.g., "avail" attribute + is "0" or "false"). 3. If an object does not require an Allocation Token, the server MAY return the availability status as available (e.g., "avail" attribute is "1" or "true"). Example domain response for a command using the extension: S: S: S: S: S: Command completed successfully S: S: S: S: - S: allocation.example - S: Allocation Token mismatch + S: allocation.example S: S: S: S: S: ABC-DEF-12345 S: 54321-XYZ S: S: S: Example command with the @@ -305,37 +304,38 @@ C: xmlns:allocationToken= C: "urn:ietf:params:xml:ns:allocationToken-1.0"> C: abc123 C: C: C: ABC-DEF-12345 C: C: Example domain response for multiple domain names in the command using the - extension: + extension, where the Allocation Token 'abc123' matches + allocation.example but does not match allocation2.example: S: S: S: S: S: Command completed successfully S: S: S: S: - S: allocation.example - S: Allocation Token mismatch + S: allocation.example S: S: - S: allocation2.example + S: allocation2.example + S: Allocation Token mismatch S: S: S: S: S: ABC-DEF-12345 S: 54321-XYZ S: S: S: @@ -768,45 +768,45 @@ 6. An Allocation Token that is signed XML should be encoded (e.g., base64 [RFC4648]) to mitigate server validation issues. 8. Acknowledgements The authors wish to acknowledge the original concept for this draft and the efforts in the initial versions of this draft by Trung Tran and Sharon Wodjenski. Special suggestions that have been incorporated into this document - were provided by Scott Hollenbeck, Benjamin Kaduk, Mirja Kuehlewind, - Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek, Eric Rescoria, and - Adam Roach. + were provided by Ben Campbell, Scott Hollenbeck, Benjamin Kaduk, + Mirja Kuehlewind, Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek, + Eric Rescoria, and Adam Roach. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + DOI 10.17487/RFC2119, March 1997, + . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, - DOI 10.17487/RFC3688, January 2004, . + DOI 10.17487/RFC3688, January 2004, + . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, - DOI 10.17487/RFC5731, August 2009, . + DOI 10.17487/RFC5731, August 2009, + . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . 9.2. Informative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, @@ -1058,20 +1058,29 @@ 7. Added "supplied" to the "If the supplied Allocation Token passed..." sentence in the "Allocation Token" section. 8. Removed an extra newline in the element in the "Allocation Token Extension Schema" section. A.16. Change from REGEXT 10 to REGEXT 11 1. Removed the old duplicate "Authorized clients MAY retrieve..." sentence from section 3.1.2 "EPP Command". +A.17. Change from REGEXT 11 to REGEXT 12 + + 1. Revised the example domain response to first include the + positive case for allocation.example, and to second include the + negative case for allocation2.example, based on feedback from Ben + Campbell. The caption was revised for the example to include the + text ", where the Allocation Token 'abc123' matches + allocation.example but does not match allocation2.example". + Authors' Addresses James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisigninc.com