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/