draft-ietf-sidr-publication-06.txt		draft-ietf-sidr-publication-07.txt
	Network Working Group S. Weiler		Network Working Group S. Weiler
	Internet-Draft SPARTA, Inc.		Internet-Draft Parsons
	Intended status: Standards Track A. Sonalker		Intended status: Standards Track A. Sonalker
	Expires: August 29, 2015 Battelle Memorial Institute		Expires: March 28, 2016 Battelle Memorial Institute
	R. Austein		R. Austein
	Dragon Research Labs		Dragon Research Labs
	February 25, 2015		September 25, 2015
	A Publication Protocol for the Resource Public Key Infrastructure (RPKI)		A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
	draft-ietf-sidr-publication-06		draft-ietf-sidr-publication-07
	Abstract		Abstract
	This document defines a protocol for publishing Resource Public Key		This document defines a protocol for publishing Resource Public Key
	Infrastructure (RPKI) objects. Even though the RPKI will have many		Infrastructure (RPKI) objects. Even though the RPKI will have many
	participants issuing certificates and creating other objects, it is		participants issuing certificates and creating other objects, it is
	operationally useful to consolidate the publication of those objects.		operationally useful to consolidate the publication of those objects.
	This document provides the protocol for doing so.		This document provides the protocol for doing so.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 http://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 August 29, 2015.		This Internet-Draft will expire on March 28, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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		(http://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
	skipping to change at page 2, line 14		skipping to change at page 2, line 14
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3		2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
	2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4		2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4
	2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 4		2.2. General Operation . . . . . . . . . . . . . . . . . . . . 4
	2.3. Listing the repository . . . . . . . . . . . . . . . . . 5		2.3. Publication and Withdrawal . . . . . . . . . . . . . . . 5
	2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 5		2.4. Listing the repository . . . . . . . . . . . . . . . . . 5
	2.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 6		2.5. Error handling . . . . . . . . . . . . . . . . . . . . . 6
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. <publish/> Query, No Existing Object . . . . . . . . . . 8		2.7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. <publish/> Query, Overwriting Existing Object . . . . . . 9		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. <publish/> Reply . . . . . . . . . . . . . . . . . . . . 9		3.1. <publish/> Query, No Existing Object . . . . . . . . . . 10
			3.2. <publish/> Query, Overwriting Existing Object . . . . . . 10
			3.3. <publish/> Reply . . . . . . . . . . . . . . . . . . . . 10
	3.4. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10		3.4. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10
	3.5. <withdraw/> Reply . . . . . . . . . . . . . . . . . . . . 10		3.5. <withdraw/> Reply . . . . . . . . . . . . . . . . . . . . 11
	3.6. <report_error/> With Text . . . . . . . . . . . . . . . . 10		3.6. <report_error/> With Optional Elements . . . . . . . . . 11
	3.7. <report_error/> Without Text . . . . . . . . . . . . . . 10		3.7. <report_error/> Without Optional Elements . . . . . . . . 11
	4. Operational Considerations . . . . . . . . . . . . . . . . . 11		3.8. Error Handling With Multi-Element Queries . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		3.8.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		3.8.2. Successful Multi-Element Response . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.8.3. Failure Multi-Element Response . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 13		4. Operational Considerations . . . . . . . . . . . . . . . . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . 13		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
			7.1. Normative References . . . . . . . . . . . . . . . . . . 17
			7.2. Informative References . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This document assumes a working knowledge of the Resource Public Key		This document assumes a working knowledge of the Resource Public Key
	Infrastructure (RPKI), which is intended to support improved routing		Infrastructure (RPKI), which is intended to support improved routing
	security on the Internet. [RFC6480]		security on the Internet. [RFC6480]
	In order to make participation in the RPKI easier, it is helpful to		In order to make participation in the RPKI easier, it is helpful to
	have a few consolidated repositories for RPKI objects, thus saving		have a few consolidated repositories for RPKI objects, thus saving
	every participant from the cost of maintaining a new service.		every participant from the cost of maintaining a new service.
	skipping to change at page 4, line 7		skipping to change at page 4, line 11
	object as the body. The server's response will similarly be the body		object as the body. The server's response will similarly be the body
	of the response with a content type of "application/rpki-		of the response with a content type of "application/rpki-
	publication".		publication".
	The content of the POST and the server's response will be a well-		The content of the POST and the server's response will be a well-
	formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID =		formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID =
	1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492].		1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492].
	2.1. Common XML Message Format		2.1. Common XML Message Format
	The XML schema for this protocol is below in Section 2.5. The basic		The XML schema for this protocol is below in Section 2.7. The basic
	XML message format looks like this:		XML message format looks like this:
	<msg		<msg
	type="query"		type="query"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<!-- Zero or more PDUs -->		<!-- Zero or more PDUs -->
	</msg>		</msg>
	<msg		<msg
	skipping to change at page 4, line 34		skipping to change at page 4, line 38
	Common attributes:		Common attributes:
	version: The value of this attribute is the version of this		version: The value of this attribute is the version of this
	protocol. This document describes version 3.		protocol. This document describes version 3.
	type: The possible values of this attribute are "reply" and "query".		type: The possible values of this attribute are "reply" and "query".
	A query PDU may be one of three types: <publish/>, <withdraw/>, or		A query PDU may be one of three types: <publish/>, <withdraw/>, or
	<list/>.		<list/>.
	A reply PDU may be one of four types: <publish/>, <withdraw/>, <list/		A reply PDU may be one of four types: <publish/>, <withdraw/>,
	>, or <report_error/>.		<list/>, or <report_error/>.
	Each of these PDUs may include an optional tag to facilitate bulk		Each of these PDUs may include an optional tag to facilitate bulk
	operation. If a tag is set in a query PDU, the corresponding		operation. If a tag is set in a query PDU, the corresponding
	reply(s) MUST have the tag attribute set to the same value.		reply(s) or error(s) MUST have the tag attribute set to the same
			value.
	2.2. Publication and Withdrawal		2.2. General Operation
			Processing of a query message is handled atomically: either the
			entire query succeeds or none of it does. When a query message
			contains multiple PDUs, failure of any PDU may require the server to
			roll back actions triggered by earlier PDUs.
			2.3. Publication and Withdrawal
	The publication protocol uses a common message format to request		The publication protocol uses a common message format to request
	publication of any RPKI object. This format was chosen specifically		publication of any RPKI object. This format was chosen specifically
	to allow this protocol to accommodate new types of RPKI objects		to allow this protocol to accommodate new types of RPKI objects
	without needing changes to this protocol.		without needing changes to this protocol.
	Both the <publish/> and <withdraw/> PDUs have a payload of an		Both the <publish/> and <withdraw/> PDUs have a payload of an
	optional tag and a URI. The <publish/> query also contains the DER		optional tag and a URI. The <publish/> query also contains the DER
	object to be published, encoded in Base64.		object to be published, encoded in Base64.
	skipping to change at page 5, line 17		skipping to change at page 5, line 28
	specified repository URI. For <withdraw/> PDUs, the hash is		specified repository URI. For <withdraw/> PDUs, the hash is
	mandatory, as this operation makes no sense if there is no existing		mandatory, as this operation makes no sense if there is no existing
	object to withdraw. For <publish/> PDUs, the hash MUST be present if		object to withdraw. For <publish/> PDUs, the hash MUST be present if
	the publication operation is overwriting an existing object, and MUST		the publication operation is overwriting an existing object, and MUST
	be omitted if this publication operation is writing to a new URI		be omitted if this publication operation is writing to a new URI
	where no prior object exists. Presence of an object when no hash		where no prior object exists. Presence of an object when no hash
	attribute is specified is an error, as is absence of the hash		attribute is specified is an error, as is absence of the hash
	attribute or an incorrect hash value when an object is present. Any		attribute or an incorrect hash value when an object is present. Any
	such errors MUST be reported using the <report_error/> PDU.		such errors MUST be reported using the <report_error/> PDU.
	The current hash algorithm is SHA-256 [SHS], to simplify comparison		The hash algorithm is SHA-256 [SHS], to simplify comparison of
	of publication protocol hashes with RPKI manifest hashes.		publication protocol hashes with RPKI manifest hashes.
	The intent behind the hash attribute is to allow the client and		The intent behind the hash attribute is to allow the client and
	server to detect any disagreements about the effect that a <publish/>		server to detect any disagreements about the effect that a <publish/>
	or <withdraw/> PDU will have on the repository.		or <withdraw/> PDU will have on the repository.
	Note that every publish and withdraw action requires a new manifest,		Note that every publish and withdraw action requires a new manifest,
	thus every publish or withdraw action will involve at least two		thus every publish or withdraw action will involve at least two
	objects.		objects.
	2.3. Listing the repository		2.4. Listing the repository
	The <list/> operation allows the client to ask the server for a		The <list/> operation allows the client to ask the server for a
	complete listing of objects which the server believes the client has		complete listing of objects which the server believes the client has
	published. This is intended primarily to allow the client to recover		published. This is intended primarily to allow the client to recover
	upon detecting (probably via use of the "hash" attribute, see		upon detecting (probably via use of the "hash" attribute, see
	Section 2.2) that they have somehow lost synchronization.		Section 2.3) that they have somehow lost synchronization.
	The <list/> query consists of a single PDU.		The <list/> query consists of a single PDU.
	The <list/> reply consists of zero or more PDUs, one per object		The <list/> reply consists of zero or more PDUs, one per object
	published in this repository by this client, each PDU conveying the		published in this repository by this client, each PDU conveying the
	URI and hash of one published object.		URI and hash of one published object.
	2.4. Error handling		2.5. Error handling
	Errors are handled at two levels.		Errors are handled at two levels.
	Since all messages in this protocol are conveyed over HTTP		Errors that make it impossible to decode a query or encode a response
	connections, basic errors are indicated via the HTTP response code.		are handled at the HTTP layer. 4xx and 5xx HTTP response codes
	4xx and 5xx responses indicate that something bad happened. Errors		indicate that something bad happened.
	that make it impossible to decode a query or encode a response are
	handled in this way.
	Where possible, errors result in an XML <report_error/> PDU which		In all other cases, errors result in an XML <report_error/> PDU which
	takes the place of the expected protocol response PDU. Like the rest		takes the place of the expected protocol response PDU. Like the rest
	of this protocol, <report_error/> PDUs are CMS-signed XML messages		of this protocol, <report_error/> PDUs are CMS-signed XML messages
	and thus can be archived to provide an audit trail.		and thus can be archived to provide an audit trail.
	<report_error/> PDUs only appear in replies, never in queries.		<report_error/> PDUs only appear in replies, never in queries.
	Like all other PDUs in this protocol, the <report_error/> PDU		Like all other reply PDUs, if a "tag" attribute was set on the query
	includes a "tag" attribute to assist in matching the error with a		that generated the error, the <report_error/> PDU MUST have its tag
	particular query when using batching. It is optional to set the tag		attribute set to the same value.
	on queries but, if set on the query, it MUST be set on the reply or
	error.
	The error itself is conveyed in the error_code attribute. The value		The error itself is conveyed in the error_code attribute. The value
	of this attribute is a token indicating the specific error that		of this attribute is a token indicating the specific error that
	occurred.		occurred.
	The body of the <report_error/> element itself is an optional text		The body of the <report_error/> element contains two sub-elements:
	string; if present, this is debugging information.
	2.5. XML Schema		1. An optional text element <error_text/>, which if present,
			contains a text string with debugging information intended for
			human consumption.
			2. An optional element <failed_pdu/>, which, if present, contains a
			verbatim copy of the query PDU whose failure triggered the
			<report_error/> PDU. The quoted element must be syntactically
			valid.
			The position of a <report_error/> element in a reply corresponds to
			the point in processing the query message where the error occurred.
			In the simple case of a query message containing only a single
			element, the <report_error/> element will be the only element in the
			reply. If, however, the query message contains more than one
			element, the <report_error/> element may be preceeded by normal
			responses indicating operations that would have succeeded.
			There are several ways that a client can match up elements in a
			response message with the corresponding elements in the query
			message:
			o For a one-element query, this is trivial.
			o For multi-element queries, the simplest way of matching resposes
			uses the optional tag attribute. The protocol requires tags from
			query elements to be copied into reply elements, so simply giving
			each query element a unique tag will suffice.
			o If for some reason the client implementation is not able or
			willing to use unique tags within a multi-element query message,
			the client can still match queries to responses by counting
			elements in the reply message. This approach is not recommended.
			See Section 3.8 for examples of a multi-element query and responses.
			2.6. Error Codes
			These are the defined error codes as well as some discussion of each.
			Text similar to these descriptions may be sent in an <error_text/>
			element to help explain the error encountered.
			permission_failure: Client does not have permission to update this
			URI.
			bad_cms_signature: Bad CMS signature.
			object_already_present: An object is already present at this URI,
			yet a hash attribute was not specified. A hash attribute must be
			specified when overwriting or deleting an object. Perhaps client
			and server are out of sync?
			no_object_present: There is no object present at this URI, yet a
			hash attribute was specified. Perhaps client and server are out
			of sync?
			no_object_matching_hash The hash attribute supplied does not match
			the hash attribute of the object at this URI. Perhaps client and
			server are out of sync?
			consistency_problem: Server detected an update that looks like it
			will cause a consistency problem (e.g. an object was deleted, but
			the manifest was not updated). Note that a server is not required
			to make such checks. Indeed, it may be unwise for a server to do
			so. This error code just provides a way for the server to explain
			its (in-)action.
			other_error: A meteor fell on the server.
			2.7. XML Schema
	The following is a RelaxNG compact form schema describing the		The following is a RelaxNG compact form schema describing the
	Publication Protocol.		Publication Protocol.
	# $Id: rpki-publication.rnc 3171 2015-02-26 00:09:05Z sra $		# $Id: rpki-publication.rnc 3407 2015-09-25 21:05:28Z sra $
	# RelaxNG schema for RPKI publication protocol.		# RelaxNG schema for RPKI publication protocol.
	default namespace =		default namespace =
	"http://www.hactrn.net/uris/rpki/publication-spec/"		"http://www.hactrn.net/uris/rpki/publication-spec/"
	# This is version 3 of the protocol.		# This is version 3 of the protocol.
	version = "3"		version = "3"
	# Top level PDU is either a query or a reply.		# Top level PDU is either a query or a reply.
	skipping to change at page 7, line 27		skipping to change at page 9, line 9
	# Publication URIs.		# Publication URIs.
	uri = attribute uri { xsd:anyURI { maxLength="4096" } }		uri = attribute uri { xsd:anyURI { maxLength="4096" } }
	# Digest of an existing object (hexadecimal).		# Digest of an existing object (hexadecimal).
	hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } }		hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } }
	# Error codes.		# Error codes.
	error = xsd:token { maxLength="1024" }		error |= "permission_failure"
			error |= "bad_cms_signature"
			error |= "object_already_present"
			error |= "no_object_present"
			error |= "no_object_matching_hash"
			error |= "consistency_problem"
			error |= "other_error"
	# <publish/> element		# <publish/> element
	publish_query = element publish { tag?, uri, hash?, base64 }		publish_query = element publish { tag?, uri, hash?, base64 }
	publish_reply = element publish { tag?, uri }		publish_reply = element publish { tag?, uri }
	# <withdraw/> element		# <withdraw/> element
	withdraw_query = element withdraw { tag?, uri, hash }		withdraw_query = element withdraw { tag?, uri, hash }
	withdraw_reply = element withdraw { tag?, uri }		withdraw_reply = element withdraw { tag?, uri }
	skipping to change at page 7, line 49		skipping to change at page 9, line 37
	# <list/> element		# <list/> element
	list_query = element list { tag? }		list_query = element list { tag? }
	list_reply = element list { tag?, uri, hash }		list_reply = element list { tag?, uri, hash }
	# <report_error/> element		# <report_error/> element
	error_reply = element report_error {		error_reply = element report_error {
	tag?,		tag?,
	attribute error_code { error },		attribute error_code { error },
	xsd:string { maxLength="512000" }?		element error_text { xsd:string { maxLength="512000" }}?,
			element failed_pdu { query_elt }?
	}		}
	3. Examples		3. Examples
	Following are examples of various queries and the corresponding		Following are examples of various queries and the corresponding
	replies for the RPKI publication protocol		replies for the RPKI publication protocol.
			Note the authors have taken liberties with the Base64, hash, and URI
			text in these examples in the interest of making the examples fit
			nicely into RFC text format.
	3.1. <publish/> Query, No Existing Object		3.1. <publish/> Query, No Existing Object
	<msg		<msg
	type="query"		type="query"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<publish
	uri="rsync://wombat.example/Alice/blCrcCp9ltyPDNzYKPfxc.cer">		uri="rsync://wombat.example/Alice/60d730635fce156f.cer">
	MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhE		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u
	RjRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4
	MDUyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIx
	OEYwNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZI
	hvcNAQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6F
	r/9Xm/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3
	F5qrKlZ4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQlu
	ffiNDjzteCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSm
	UDuZ1HDz1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/
	o8qFdC300VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mG
	aA1jgAxlXWsCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I
	8M3Ngo9/FzAfBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNV
	HR8ETjBMMEqgSKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQv
	UklSLzEvMzBxQUYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEF
	BQcBAQQ5MDcwNQYIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAv
	dGVzdGJlZC9XT01CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw
	DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwEL
	BIGOMIGLMDQGCCsGAQUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rl
	c3RiZWQvUklSL1IwLzEvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9z
	dDo0NDAwL3Rlc3RiZWQvUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56
	WUtQZnhjLm1uZjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYB
	BQUHAQcBAf8ELzAtMCsEAgABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMF
	AsAAAiwDBQDAAAJkMA0GCSqGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv
	306vmCuXhtu9Lr2mmRw2ZErB8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yATh
	M81FPNRsU5mM0acIRnAPtxjHvPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFUR
	azENztppsolHeTpm0cpLItK7mNpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel
	/SM/UvOArCCOBvf0Gz7kSuupDSZ7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxd
	x28qIj7ejZkRzNFw/3pi8/XK281h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx
	0iwPYdLiDbdWFbtTdPcXBauY
	</publish>		</publish>
	</msg>		</msg>
	3.2. <publish/> Query, Overwriting Existing Object		3.2. <publish/> Query, Overwriting Existing Object
	<msg		<msg
	type="query"		type="query"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<publish
	hash="deadf00d"		hash="60d730635fce156f"
	uri="rsync://wombat.example/Alice/blCrcCp9ltyPDNzYKPfxc.cer">		uri="rsync://wombat.example/Alice/60d730635fce156f.cer">
	MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyhE		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u
	RjRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XDTA4
	MDUyMjE4MDUxMloXDTA4MDUyNDE3NTQ1M1owMzExMC8GA1UEAxMoOEZCODIx
	OEYwNkU1MEFCNzAyQTdEOTZEQzhGMENEQ0Q4MjhGN0YxNzCCASIwDQYJKoZI
	hvcNAQEBBQADggEPADCCAQoCggEBAMeziKp0k5nP7v6SZoNsXIMQYRgNtC6F
	r/9Xm/1yQHomiPqHUk47rHhGojYiK5AhkrwoYhkH4UjJl2iwklDYczXuaBU3
	F5qrKlZ4aZnjIxdlP7+hktVpeApL6yuJTUAYeC3UIxnLDVdD6phydZ/FOQlu
	ffiNDjzteCCvoyOUatqt8WB+oND6LToHp028g1YUYLHG6mur0dPdcHOVXLSm
	UDuZ1HDz1nDuYvIVKjB/MpH9aW9XeaQ6ZFIlZVPwuuvI2brR+ThH7Gv27GL/
	o8qFdC300VQfoTZ+rKPGDE8K1cI906BL4kiwx9z0oiDcE96QCz+B0vsjc9mG
	aA1jgAxlXWsCAwEAAaOCAhcwggITMB0GA1UdDgQWBBSPuCGPBuUKtwKn2W3I
	8M3Ngo9/FzAfBgNVHSMEGDAWgBTfSoAX5mqekXLkYS2M9Mg/I43iozBVBgNV
	HR8ETjBMMEqgSKBGhkRyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rlc3RiZWQv
	UklSLzEvMzBxQUYtWnFucEZ5NUdFdGpQVElQeU9ONHFNLmNybDBFBggrBgEF
	BQcBAQQ5MDcwNQYIKwYBBQUHMAKGKXJzeW5jOi8vbG9jYWxob3N0OjQ0MDAv
	dGVzdGJlZC9XT01CQVQuY2VyMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIw
	DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwgZsGCCsGAQUFBwEL
	BIGOMIGLMDQGCCsGAQUFBzAFhihyc3luYzovL2xvY2FsaG9zdDo0NDAwL3Rl
	c3RiZWQvUklSL1IwLzEvMFMGCCsGAQUFBzAKhkdyc3luYzovL2xvY2FsaG9z
	dDo0NDAwL3Rlc3RiZWQvUklSL1IwLzEvajdnaGp3YmxDcmNDcDlsdHlQRE56
	WUtQZnhjLm1uZjAaBggrBgEFBQcBCAEB/wQLMAmgBzAFAgMA/BUwPgYIKwYB
	BQUHAQcBAf8ELzAtMCsEAgABMCUDAwAKAzAOAwUAwAACAQMFAcAAAiAwDgMF
	AsAAAiwDBQDAAAJkMA0GCSqGSIb3DQEBCwUAA4IBAQCEhuH7jtI2PJY6+zwv
	306vmCuXhtu9Lr2mmRw2ZErB8EMcb5xypMrNqMoKeu14K2x4a4RPJkK4yATh
	M81FPNRsU5mM0acIRnAPtxjHvPME7PHN2w2nGLASRsZmaa+b8A7SSOxVcFUR
	azENztppsolHeTpm0cpLItK7mNpudUg1JGuFo94VLf1MnE2EqARG1vTsNhel
	/SM/UvOArCCOBvf0Gz7kSuupDSZ7qx+LiDmtEsLdbGNQBiYPbLrDk41PHrxd
	x28qIj7ejZkRzNFw/3pi8/XK281h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx
	0iwPYdLiDbdWFbtTdPcXBauY
	</publish>		</publish>
	</msg>		</msg>
	3.3. <publish/> Reply		3.3. <publish/> Reply
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<publish
	uri="rsync://wombat.example/Alice/blCrcCp9ltyPDNzYKPfxc.cer"/>		uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
	</msg>		</msg>
	3.4. <withdraw/> Query		3.4. <withdraw/> Query
	<msg		<msg
	type="query"		type="query"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<withdraw		<withdraw
	hash="deadf00d"		hash="60d730635fce156f"
	uri="rsync://wombat.example/Alice/blCrcCp9ltyPDNzYKPfxc.cer"/>		uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
	</msg>		</msg>
	3.5. <withdraw/> Reply		3.5. <withdraw/> Reply
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<withdraw		<withdraw
	uri="rsync://wombat.example/Alice/blCrcCp9ltyPDNzYKPfxc.cer"/>		uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
	</msg>		</msg>
	3.6. <report_error/> With Text		3.6. <report_error/> With Optional Elements
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<report_error		<report_error
	error_code="your_hair_is_on_fire">		error_code="no_object_matching_hash">
	Shampooing with sterno again, are we?		<error_text>
			Can't delete an object I don't have
			</error_text>
			<failed_pdu>
			<publish
			hash="60d730635fce156f"
			uri="rsync://wombat.example/Alice/60d730635fce156f.cer">
			WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u
			</publish>
			</failed_pdu>
	</report_error>		</report_error>
	</msg>		</msg>
	3.7. <report_error/> Without Text		3.7. <report_error/> Without Optional Elements
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<report_error		<report_error
	error_code="your_hair_is_on_fire"/>		error_code="object_already_present"/>
			</msg>
			3.8. Error Handling With Multi-Element Queries
			3.8.1. Multi-Element Query
			<msg
			type="query"
			version="3"
			xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<publish
			tag="Alice"
			uri="rsync://wombat.example/Alice/3bc51062973c458d.cer">
			QWxpY2U=
			</publish>
			<withdraw
			hash="cd9fb1e148ccd844"
			tag="Bob"
			uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
			<publish
			tag="Carol"
			uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer">
			Q2Fyb2w=
			</publish>
			<list/>
			<withdraw
			hash="809a721743350c0c"
			tag="Dave"
			uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>
			<publish
			tag="Eve"
			uri="rsync://wombat.example/Eve/b9bae658d9657985.cer">
			RXZl
			</publish>
			</msg>
			3.8.2. Successful Multi-Element Response
			<msg
			type="reply"
			version="3"
			xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<publish
			tag="Alice"
			uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"/>
			<withdraw
			tag="Bob"
			uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
			<publish
			tag="Carol"
			uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"/>
			<list
			hash="f842c3e1858df8c8"
			uri="rsync://wombat.example/Fee/f842c3e1858df8c8.cer"/>
			<list
			hash="b139ca23414476bb"
			uri="rsync://wombat.example/Fie/b139ca23414476bb.cer"/>
			<list
			hash="1995e9544ba80191"
			uri="rsync://wombat.example/Foe/1995e9544ba80191.cer"/>
			<list
			hash="9c00b310c10a022c"
			uri="rsync://wombat.example/Fum/9c00b310c10a022c.cer"/>
			<withdraw
			tag="Dave"
			uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>
			<publish
			tag="Eve"
			uri="rsync://wombat.example/Eve/b9bae658d9657985.cer"/>
			</msg>
			3.8.3. Failure Multi-Element Response
			<msg
			type="reply"
			version="3"
			xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<publish
			tag="Alice"
			uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"/>
			<withdraw
			tag="Bob"
			uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
			<publish
			tag="Carol"
			uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"/>
			<list
			hash="f842c3e1858df8c8"
			uri="rsync://wombat.example/Fee/f842c3e1858df8c8.cer"/>
			<list
			hash="b139ca23414476bb"
			uri="rsync://wombat.example/Fie/b139ca23414476bb.cer"/>
			<list
			hash="1995e9544ba80191"
			uri="rsync://wombat.example/Foe/1995e9544ba80191.cer"/>
			<list
			hash="9c00b310c10a022c"
			uri="rsync://wombat.example/Fum/9c00b310c10a022c.cer"/>
			<report_error
			error_code="no_object_matching_hash"
			tag="Dave">
			<failed_pdu>
			<withdraw
			hash="809a721743350c0c"
			tag="Dave"
			uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>
			</failed_pdu>
			</report_error>
	</msg>		</msg>
	4. Operational Considerations		4. Operational Considerations
	There are two basic options open to the repository operator as to how		There are two basic options open to the repository operator as to how
	the publication tree is laid out. The first option is simple: each		the publication tree is laid out. The first option is simple: each
	publication client is given its own directory one level below the top		publication client is given its own directory one level below the top
	of the rsync module, and there is no overlap between the publication		of the rsync module, and there is no overlap between the publication
	spaces used by different clients. For example:		spaces used by different clients. For example:
	skipping to change at page 13, line 41		skipping to change at page 17, line 32
	fips-180-4.pdf>.		fips-180-4.pdf>.
	7.2. Informative References		7.2. Informative References
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, February 2012.		Secure Internet Routing", RFC 6480, February 2012.
	Authors' Addresses		Authors' Addresses
	Samuel Weiler		Samuel Weiler
	SPARTA, Inc.		Parsons
	7110 Samuel Morse Drive
	Columbia, Maryland 21046
	US
	Email: weiler@tislabs.com		Email: weiler@tislabs.com
	Anuja Sonalker		Anuja Sonalker
	Battelle Memorial Institute		Battelle Memorial Institute
	Email: sonalkera@battelle.org		Email: sonalkera@battelle.org
	Rob Austein		Rob Austein
	Dragon Research Labs		Dragon Research Labs
	Email: sra@hactrn.net		Email: sra@hactrn.net
End of changes. 36 change blocks.
	125 lines changed or deleted		271 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/