draft-ietf-p2psip-sip-02.txt		draft-ietf-p2psip-sip-03.txt
	P2PSIP C. Jennings		P2PSIP C. Jennings
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track B. Lowekamp, Ed.		Intended status: Standards Track B. Lowekamp, Ed.
	Expires: April 9, 2010 MYMIC LLC		Expires: April 25, 2010 MYMIC LLC
	E. Rescorla		E. Rescorla
	Network Resonance		Network Resonance
	S. Baset		S. Baset
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	October 6, 2009		October 22, 2009
	A SIP Usage for RELOAD		A SIP Usage for RELOAD
	draft-ietf-p2psip-sip-02		draft-ietf-p2psip-sip-03
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 9, 2010.		This Internet-Draft will expire on April 25, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 8, line 26		skipping to change at page 8, line 26
	Note that this structure explicitly allows one Node-ID to forward to		Note that this structure explicitly allows one Node-ID to forward to
	another Node-ID. For instance, Alice could set calls to her desk		another Node-ID. For instance, Alice could set calls to her desk
	phone to ring at her cell phone. It's not clear that this is useful		phone to ring at her cell phone. It's not clear that this is useful
	in this case, but may be useful if Alice has two AORs.		in this case, but may be useful if Alice has two AORs.
	In order to prevent hijacking, registrations are subject to access		In order to prevent hijacking, registrations are subject to access
	control rules. Before a Store is permitted, the storing peer MUST		control rules. Before a Store is permitted, the storing peer MUST
	check that:		check that:
	o The certificate contains a username that is a SIP AOR that hashes		o The certificate contains a username that is a SIP AOR that hashes
	to the Resource-ID being stored at.		to the Resource-ID it is being stored at.
	o The certificate contains a Node-ID that is the same as the		o The certificate contains a Node-ID that is the same as the
	dictionary key being stored at.		dictionary key it is being stored at.
	Note that these rules permit Alice to forward calls to Bob without		Note that these rules permit Alice to forward calls to Bob without
	his permission. However, they do not permit Alice to forward Bob's		his permission. However, they do not permit Alice to forward Bob's
	calls to her. See Section 8.2.2 for more on this point.		calls to her. See Section 8.2.2 for more on this point.
	4. Looking up an AOR		4. Looking up an AOR
	When a RELOAD user wishes to call another user, starting with a non-		When a RELOAD user wishes to call another user, starting with a non-
	GRUU AOR, he follows the following procedure. (GRUUs are discussed		GRUU AOR, he follows the following procedure. (GRUUs are discussed
	in Section 6).		in Section 6).
	1. Check to see if the domain part of the AOR matches the domain		1. Check to see if the domain part of the AOR matches the domain
	name of an overlay of which he is a member. If not, then this is		name of an overlay of which he is a member. If not, then this is
	an external AOR, and he MUST do one of the following:		an external AOR, and he MUST do one of the following:
	* Fail the call.		* Fail the call.
	* Use ordinary SIP procedures.		* Use ordinary SIP procedures.
	* Attempt to become a member of the overlay indicated by the		* Attempt to become a member of the overlay indicated by the
	domain part, if that overlay is a RELOAD overlay.)		domain part, if that overlay is a RELOAD overlay.)
	2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID		2. Perform a Fetch for kind SIP-REGISTRATION at the Resource-ID
	corresponding to the AOR. This Fetch SHOULD NOT indicate any		corresponding to the AOR. This Fetch SHOULD NOT indicate any
	dictionary keys, which will result in fetching all the stored		dictionary keys, so that it will fetch all the stored values.
	values.
	3. If any of the results of the Fetch are non-GRUU AORs, then repeat		3. If any of the results of the Fetch are non-GRUU AORs, then repeat
	step 1 for that AOR.		step 1 for that AOR.
	4. Once only GRUUs and destination lists remain, the peer removes		4. Once only GRUUs and destination lists remain, the peer removes
	duplicate destination lists and GRUUs from the list and forms a		duplicate destination lists and GRUUs from the list and forms a
	SIP connection to the appropriate peers as described in the		SIP connection to the appropriate peers as described in the
	following sections. If there are also external AORs, the peer		following sections. If there are also external AORs, the peer
	follows the appropriate procedure for contacting them as well.		follows the appropriate procedure for contacting them as well.
	5. Forming a Direct Connection		5. Forming a Direct Connection
	skipping to change at page 11, line 36		skipping to change at page 11, line 36
	This draft is a merge of the "REsource LOcation And Discovery		This draft is a merge of the "REsource LOcation And Discovery
	(RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B.		(RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B.
	Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen		Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen
	Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security		Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security
	Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick,		Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick,
	the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia		the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia
	Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP)		Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP)
	draft by Salman A. Baset, Henning Schulzrinne, and Marcin		draft by Salman A. Baset, Henning Schulzrinne, and Marcin
	Matuszewski.		Matuszewski.
	Thanks to the many people who contributed including: Michael Chen,		Thanks to Michael Chen for his contributions.
	TODO - fill in.
	11. References		11. References
	11.1. Normative References		11.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[I-D.ietf-p2psip-base]		[I-D.ietf-p2psip-base]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
End of changes. 8 change blocks.
	10 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/