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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/