< draft-winterbottom-geopriv-lis2lis-req-00.txt		draft-winterbottom-geopriv-lis2lis-req-01.txt >
	Geopriv J. Winterbottom		Geopriv J. Winterbottom
	Internet-Draft Andrew Corporation		Internet-Draft Andrew Corporation
	Intended status: Standards Track S. Norreys		Intended status: Standards Track S. Norreys
	Expires: December 16, 2007 British Telecom		Expires: May 22, 2008 British Telecom
	June 14, 2007		November 19, 2007
	LIS to LIS Protocol Requirements		LIS to LIS Protocol Requirements
	draft-winterbottom-geopriv-lis2lis-req-00.txt		draft-winterbottom-geopriv-lis2lis-req-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 December 16, 2007.		This Internet-Draft will expire on May 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes requirements for a LIS to LIS protocol and		This document describes requirements for a LIS to LIS protocol and
	provides examples of where such a protocol is applicable.		provides examples of where such a protocol is applicable.
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	However, when the connectivity information held by the two parties is		However, when the connectivity information held by the two parties is
	combined the location of the end-point can be determined.		combined the location of the end-point can be determined.
	2. Terminology		2. Terminology
	The key conventions and terminology used in this document are defined		The key conventions and terminology used in this document are defined
	as follows:		as follows:
	This document reuses the terms Target, as defined in [RFC3693].		This document reuses the terms Target, as defined in [RFC3693].
	This document uses the term Location Information Server, LIS, to		This document uses the term Location Information Server (LIS) as
	represent a combined Location Server and Location Generator (as		defined in [I-D.ietf-geopriv-l7-lcp-ps].
	defined in [RFC3693]) residing inside the local access domain.
	Broadband Remote Access Server (BRAS). A node in a DSL network		Broadband Remote Access Server (BRAS). A node in a DSL network
	responsible for switching data streams between end-points and		responsible for switching data streams between end-points and
	Internet Service Providers.		Internet Service Providers.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Overview		3. Overview
	The Geopriv L7 LCP requirements [I-D.ietf-geopriv-l7-lcp-ps] describe		The Geopriv L7 LCP requirements [I-D.ietf-geopriv-l7-lcp-ps] describe
	a range of network topologies in which a Target should be able to		a range of network topologies in which a Target should be able to
	acquire its location from a LIS using an application layer location		acquire its location from a LIS using an application layer location
	acquisition protocol. The scope of [I-D.ietf-geopriv-l7-lcp-ps] is		acquisition protocol. The scope of [I-D.ietf-geopriv-l7-lcp-ps] is
	such that it does not address specific network topologies that may		such that it does not address specific network topologies that may
	exist inside access network provider domain. This document provides		exist inside the access network provider domain. This document
	scope and requirements for LIS to LIS communications where the two		provides scope and requirements for LIS to LIS communications where
	servers are controlled by different operators each running a part of		the two servers are controlled by different operators each running a
	the access provider network. While the same principles may be		part of the access network. While the same principles may be applied
	applied to inter-LIS communication occurring between a LIS in the		to inter-LIS communication occurring between a LIS in the customer
	customer premise network and the access provider network, operation		premise network and the access provider network, operation in this
	in this configuration is not considered in scope for this document.		configuration is not considered in scope for this document.
	+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+		+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
	| | | |		| | | |
	| Regional | | INTERNET Service |		| Regional | | INTERNET Service |
	| Access Network Provider | | Provider |		| Access Network Provider | | Provider |
	| | | +------------------+ |		| | | +------------------+ |
	| +------------+ | | | Network Access | |		| +------------+ | | | Network Access | |
	| | Switching |-------------------------->| Server | |		| | Switching |-------------------------->| Server | |
	| +------------+ | | +------------------+ |		| +------------+ | | +------------------+ |
	| ^ | +-----+ | | +-----+ | |		| ^ | +-----+ | | +-----+ | |
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 13 ¶
	This document describes the requirements for this information flow.		This document describes the requirements for this information flow.
	4. Assumptions		4. Assumptions
	This section details the high-level assumptions made in this		This section details the high-level assumptions made in this
	document.		document.
	1: A strong trust relationship exists between the regional access		1: A strong trust relationship exists between the regional access
	provider and ISP.		provider and ISP.
	2: End-points only deal directly with the ISP LIS, and may be totally		2: Targets only deal directly with the ISP LIS, and may be totally
	unaware of any regional access provider LIS. A regional access		unaware of any regional access provider LIS. A regional access
	LIS will only ever receive location requests from an ISP LIS.		LIS will only ever receive location requests from an ISP LIS.
	5. Requirements		5. Requirements
	This section details the requirements that MUST be satisfied by any		This section details the requirements that MUST be satisfied by any
	LIS to LIS protocol		LIS to LIS protocol
	1: Connections (physical and logical) from the ISP LIS to the		1: Connections (physical and logical) from the ISP LIS to the
	regional access LIS require both ends to authenticate as part of		regional access LIS require both ends to authenticate as part of
	connection establishment. The security of the data conveyed		connection establishment. The security of the data conveyed
	between the two servers MUST be ensured for both privacy and		between the two servers MUST be ensured for both privacy and
	integrity.		integrity.
	2: The data used to identify an end-point to the ISP MUST be able to		2: The data used to identify a Target to the ISP MUST be able to be
	be passed to, and be recognizable by the regional access LIS using		passed to, and be recognizable by the regional access LIS using
	the LIS to LIS protocol. The data used to identify an end-point		the LIS to LIS protocol. The data used to identify a Target to
	to the ISP MUST be consistent with the traffic aggregation method		the ISP MUST be consistent with the traffic aggregation method
	supported by the Regional Access Network Provider.		supported by the Regional Access Network Provider.
	3: Location information returned over a LIS to LIS protocol MUST be		3: Location information returned over a LIS to LIS protocol MUST be
	in PIDF-LO [RFC4119] format, and MUST comply with		in PIDF-LO [RFC4119] format, and MUST comply with
	[I-D.ietf-geopriv-pdif-lo-profile] .		[I-D.ietf-geopriv-pdif-lo-profile] .
	4: The type of location information requested by the end-point MUST		4: The type of location information requested by the end-point MUST
	be relayed to the regional access LIS by the ISP LIS using the LIS		be relayed to the regional access LIS by the ISP LIS using the LIS
	to LIS protocol.		to LIS protocol.
	5: The method used by the regional access LIS to determine the		5: The method used by the regional access LIS to determine the
	location of the end-point MUST be provided to the ISP LIS along		location of the Target MUST be provided to the ISP LIS along with
	with the determined location.		the determined location.
	6: Any usage-rule preferences provided by the end-point to the ISP		6: Any usage-rule preferences provided by the Target to the ISP LIS
	LIS MUST be included in any location returned to the end-point.		MUST be included in any location returned to the Target or
			Location Recipient.
	7: Where location signing is requested by the end-point, this request		7: Additional information provided by the Target to the ISP in a
			location request that cannot be processed directly by the ISP LIS
	MUST be forwarded to regional access LIS using the LIS to LIS		MUST be forwarded to regional access LIS using the LIS to LIS
	protocol		protocol. The intention of this requirement is to support future
			LCP functions that require additional information from the Target.
	8: The presentity in the PIDF-LO returned by the regional access LIS		8: The presentity in the PIDF-LO returned by the regional access LIS
	MUST have been provided by the ISP LIS. The ISP LIS may create		MUST have been provided by the ISP LIS. The ISP LIS may create
	the presentity, or it may have received a presentity from the end-		the presentity, or it may have received a presentity from the
	point.		Target.
	9: The protocol MUST provide support for returning and dealing with		9: The protocol MUST provide support for returning and dealing with
	error conditions such as "no location found" or "timeout".		error conditions such as "no location found" or "timeout".
	6. Security Considerations		6. Security Considerations
	LIS to LIS communications are necessary in some network architectures		LIS to LIS communications are necessary in some network architectures
	and care must be taken to ensure that they are secure both from a		and care must be taken to ensure that they are secure both from a
	privacy perspective and from an integrity perspective. This can be		privacy perspective and from an integrity perspective. This can be
	achieved in the most part with existing protocol suites, such as TLS,		achieved in the most part with existing protocol suites, such as TLS,
	skipping to change at page 12, line 8 ¶		skipping to change at page 12, line 8 ¶
	Operators of regional access servers will need to ensure that this		Operators of regional access servers will need to ensure that this
	operational requirement is met.		operational requirement is met.
	7. IANA Considerations		7. IANA Considerations
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	8. Acknowledgements		8. Acknowledgements
	Thanks to Guy Caron and Barbara Stark for providing early reviews of		Thanks to Guy Caron and Barbara Stark for providing early reviews of
	this document.		this document. Thanks to Martin Thomson and Cullen Jennings for
			providing comments.
	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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[I-D.ietf-geopriv-l7-lcp-ps]		[I-D.ietf-geopriv-l7-lcp-ps]
	Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol; Problem Statement and		Location Configuration Protocol; Problem Statement and
	Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in		Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
	progress), April 2007.		progress), September 2007.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[I-D.ietf-geopriv-pdif-lo-profile]		[I-D.ietf-geopriv-pdif-lo-profile]
	Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,		Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	Considerations and Recommendations",		PIDF-LO Usage Clarification, Considerations and
	draft-ietf-geopriv-pdif-lo-profile-07 (work in progress),		Recommendations", draft-ietf-geopriv-pdif-lo-profile-10
	April 2007.		(work in progress), October 2007.
	9.2. Informative references		9.2. Informative references
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	Andrew Corporation		Andrew Corporation
End of changes. 15 change blocks.
	34 lines changed or deleted		37 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/