< draft-wendt-modern-drip-00.txt		draft-wendt-modern-drip-01.txt >
	Internet Engineering Task Force H. Bellur		Internet Engineering Task Force H. Bellur
	Internet-Draft C. Wendt, Ed.		Internet-Draft C. Wendt, Ed.
	Intended status: Standards Track Comcast		Intended status: Standards Track Comcast
	Expires: April 21, 2016 October 19, 2015		Expires: January 9, 2017 July 8, 2016
	Distributed Registry Protocol		Distributed Registry Protocol
	draft-wendt-modern-drip-00		draft-wendt-modern-drip-01
	Abstract		Abstract
	This document describes a protocol for allowing a distributed set of		This document describes a protocol for allowing a distributed set of
	nodes to synchronize a set of information in real-time with minimal		nodes to synchronize a set of information in real-time with minimal
	amount of delay. This is useful for registry types of information		amount of delay. This is useful for registry types of information
	like identity and telephone numbers with associated routing and		like identity and telephone numbers with associated routing and
	ownership information and could be extended to support other		ownership information and could be extended to support other
	distributed real-time information updates as well.		distributed real-time information updates as well.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 April 21, 2016.		This Internet-Draft will expire on January 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	4.4. Key-Value Data Propagation Rules . . . . . . . . . . . . 8		4.4. Key-Value Data Propagation Rules . . . . . . . . . . . . 8
	4.5. Key-Value Data Update . . . . . . . . . . . . . . . . . . 8		4.5. Key-Value Data Update . . . . . . . . . . . . . . . . . . 8
	4.5.1. Voting Phase . . . . . . . . . . . . . . . . . . . . 9		4.5.1. Voting Phase . . . . . . . . . . . . . . . . . . . . 9
	4.5.1.1. API - POST /voting . . . . . . . . . . . . . . . 10		4.5.1.1. API - POST /voting . . . . . . . . . . . . . . . 10
	4.5.1.2. POST /votingphase/node/:nodeid/response/:response 11		4.5.1.2. POST /votingphase/node/:nodeid/response/:response 11
	4.5.2. Commit Phase . . . . . . . . . . . . . . . . . . . . 11		4.5.2. Commit Phase . . . . . . . . . . . . . . . . . . . . 11
	4.5.2.1. API - POST /commit . . . . . . . . . . . . . . . 12		4.5.2.1. API - POST /commit . . . . . . . . . . . . . . . 12
	4.6. Node Sync Operation . . . . . . . . . . . . . . . . . . . 13		4.6. Node Sync Operation . . . . . . . . . . . . . . . . . . . 13
	4.6.1. API - PUT /sync/node/:nodeid . . . . . . . . . . . . 13		4.6.1. API - PUT /sync/node/:nodeid . . . . . . . . . . . . 13
	4.7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . 14		4.7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.8. Key-Value Data Update Entitlement Verification . . . . . 14		4.7.1. API - POST /heartbeat/node/:nodeid . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		4.8. Key-Value Data Update Entitlement Verification . . . . . 15
	5.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	5.2. Authentication . . . . . . . . . . . . . . . . . . . . . 14		5.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		5.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		5.3. Payload Validation . . . . . . . . . . . . . . . . . . . 15
			6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document describes the Distributed Registry Protocol (DRiP).		This document describes the Distributed Registry Protocol (DRiP).
	DRiP defines a set of peer protocols for how an arbitrary number of		DRiP defines a set of peer protocols for how an arbitrary number of
	nodes arranged in a distributed mesh architecture can be used to		nodes arranged in a distributed mesh architecture can be used to
	synchronize data in real-time across a network.		synchronize data in real-time across a network.
	1.1. Terminology		1.1. Terminology
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	The peer node should maintain a state that defines whether it is		The peer node should maintain a state that defines whether it is
	active, inactive, or synchronizing key-value data with a peer node.		active, inactive, or synchronizing key-value data with a peer node.
	The node should proactively tell it's peer nodes its state by sending		The node should proactively tell it's peer nodes its state by sending
	the following POST messages. The GET query is available for nodes to		the following POST messages. The GET query is available for nodes to
	query the state of peer nodes.		query the state of peer nodes.
	4.2.1. API - POST /node/:nodeid/active		4.2.1. API - POST /node/:nodeid/active
	Request:		Example (using cURL)
	POST /node/:nodeid/active
	Description:		Request
	TBD		$ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..."
			-X POST https://nodearegistry.com/node/nodeA/active
	Example:		Response
	TBD		HTTP/1.1 200 OK
	4.2.2. API - POST /node/:nodeid/inactive		4.2.2. API - POST /node/:nodeid/inactive
	Request:		Example (using cURL)
	GET /state		Request
			$ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..."
			-X POST https://nodearegistry.com/node/nodeA/inactive
			Response
			HTTP/1.1 200 OK
			4.2.3. API - GET /state
	Description:		Description:
	A node should query the state of its peer node before it initiates a		A node should query the state of its peer node before it initiates a
	sync operation. This request responds with either "active" or "sync"		sync operation. This request responds with either "active" or "sync"
	or no response, if in "inactive" state.		or no response, if in "inactive" state.
	Example:		Example (using cURL)
			Request
	TBD
	4.2.3. API - GET /state
	Request:
	POST /node/:nodeid/active		$ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..."
	Description:		-X GET https://nodearegistry.com/state
	TBD		Response
	Example:		HTTP/1.1 200 OK with the following JSON object.
	TBD		+---------------+----------------------------------+
			| Property | Description |
			+---------------+----------------------------------+
			| state | "active" or "inactive" or "sync" |
			+---------------+----------------------------------+
	4.3. Custom HTTP header fields		4.3. Custom HTTP header fields
	Custom HTTP header fields will be used to carry node specific		Custom HTTP header fields will be used to carry node specific
	information.		information.
	+---------------+---------------------------------------------------+		+---------------+---------------------------------------------------+
	| Field Name | Description |		| Field Name | Description |
	+---------------+---------------------------------------------------+		+---------------+---------------------------------------------------+
	| DRiP-Node-ID | Each node in the mesh MUST have a unique |		| DRiP-Node-ID | Each node in the mesh MUST have a unique |
	skipping to change at page 13, line 51 ¶		skipping to change at page 13, line 51 ¶
	Description:		Description:
	API call for initiating a full registry synchronization from node to		API call for initiating a full registry synchronization from node to
	peer-node.		peer-node.
	Example (using cURL)		Example (using cURL)
	Request		Request
	$ TBD		$ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..."
			-X POST https://peernode.com/sync/node/nodeA
	Response		Response
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	4.7. Heartbeat		4.7. Heartbeat
	TBD - definition of heartbeat		Periodic heartbeats are required for a node to determine it's
			visibility to the rest of it's peer nodes and whether it should put
			itself in "inactive" mode. The proceedure for heartbeats is as
			follows.
	TBD - determination of the need to sync after heartbeat fails		A node sends periodic heartbeat requests to its peer nodes with an
			indication of its state. These heartbeat requests are not to be
			propagated beyond the peer nodes.
			If all of its peer nodes cannot be reached or do not respond with 200
			OK, then the node that sent the heartbeat request will set its own
			state to "inactive". This is based on the reasonable assumption that
			none of the peer nodes are able to communicate with this node until a
			new heartbeat request is sucessful. Once in the inactive state, the
			node will
			o not propagate any incoming key-value data
			o not update any incoming key-value data
			o continue to send the periodic heartbeat requests to its peer
			nodes. If any one responds with 200 OK, then the node will move
			its state to "synchronizing" and will re-synchronize its data with
			any active peer node as detailed in section 4.6
			In addition, any one or more peer nodes that cannot be reached or did
			not respond with 200 OK should not be used to propagate key-value
			data until it responds (with 200 OK) to the heartbeat request.
			4.7.1. API - POST /heartbeat/node/:nodeid
			Example (using cURL)
			Request
			$ curl -i -H "DRiP-Node-ID: nodeA" -H "Authorization: eyJ0e..."
			-X POST -d '<state>' https://peernode.com/heartbeat/node/nodeA
			Response
			HTTP/1.1 200 OK
	4.8. Key-Value Data Update Entitlement Verification		4.8. Key-Value Data Update Entitlement Verification
	When a node owner would like to create or modify particular key-value		When a node owner would like to create or modify particular key-value
	data, generally in the context of a registry, there MAY be a		data, generally in the context of a registry, there MAY be a
	verification procedure that key-value data write or modification can		verification procedure that key-value data write or modification can
	be performed. This could include validating whether key-value data		be performed. This could include validating whether key-value data
	is entitled to be written, modified or subsequently propagated based		is entitled to be written, modified or subsequently propagated based
	on application policy. For example, identity or telephone number		on application policy. For example, identity or telephone number
	ownership or porting. The exact mechanics of this are out of scope		ownership or porting. The exact mechanics of this are out of scope
	of this document and are generally application specific.		of this document and are generally application specific.
	5. Security Considerations		5. Security Considerations
	5.1. HTTPS		5.1. HTTPS
	All nodes MUST perform HTTP transactions using TLS as defined in		All nodes MUST perform HTTP transactions using TLS as defined in
	[RFC7230].		[RFC7230].
	5.2. Authentication		5.2. Authorization
	Secure authentication of node to node communication is beyond the		All nodes MUST validate their authority to consume the HTTP APIs of a
	scope of this document, however best practices in terms of protecting		peer node by adding a JSON Web Token (JWT) value [RFC7519] in the
	the node API interface should be followed.		Authorization request-header field.
			The creation and verification of the JWT should be based on a digital
			signature. For most distributed registry scenerios where the owner
			of a node may not have a direct relationship with another node owner,
			a PKI based certificate approach is highly suggested. For protection
			against replay attacks, the claim set SHOULD contain an "iat" claim
			and the signature should be verified to be signed by the expected
			owner of the peer node. The "iat" claim identifies the time at which
			the JWT was issued and can be used to validate when the time of the
			transaction occurred.
			5.3. Payload Validation
			In addition to the DRiP level protocol protection, it is highly
			suggested to sign and validate part or all of the JSON update
			payloads to the originator of the update. DRiP does not define
			anything regarding the contents of the payload, so this document does
			not address this in any way.
	6. References		6. 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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing", RFC		Protocol (HTTP/1.1): Message Syntax and Routing",
	7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
			[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
			(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
			<http://www.rfc-editor.org/info/rfc7519>.
	Authors' Addresses		Authors' Addresses
	Harsha Bellur		Harsha Bellur
	Comcast		Comcast
	One Comcast Center		One Comcast Center
	Philadelphia, PA 19103		Philadelphia, PA 19103
	USA		USA
	Email: Harsha_Bellur@cable.comcast.com		Email: Harsha_Bellur@cable.comcast.com
End of changes. 25 change blocks.
	42 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/