draft-ietf-geopriv-sip-lo-retransmission-00.txt   draft-ietf-geopriv-sip-lo-retransmission-01.txt 
GEORIV T. Hardie Internet Engineering Task Force J. Peterson
Internet-Draft Qualcomm, Inc. Internet-Draft NeuStar, Inc.
Intended status: Standards Track J. Peterson Intended status: Informational T. Hardie
Expires: January 4, 2009 NeuStar, Inc. Expires: April 29, 2009 Qualcomm
J. Morris J. Morris
Center for Democracy and CDT
Technology October 26, 2008
July 3, 2008
Implications of <retransmission-allowed> for SIP Location Conveyance Implications of 'retransmission-allowed' for SIP Location Conveyance
draft-ietf-geopriv-sip-lo-retransmission-00.txt draft-ietf-geopriv-sip-lo-retransmission-01
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 38 skipping to change at page 1, line 37
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 January 4, 2009. This Internet-Draft will expire on April 29, 2009.
Abstract Abstract
This document explores an ambiguity in the interpretation of the This document explores an ambiguity in the interpretation of the
<retransmission-allowed> element of the Presence Information Data <retransmission-allowed> element of the Presence Information Data
Format for Location Objects (PIDF-LO) in cases where PIDF-LO is Format for Location Objects (PIDF-LO) in cases where PIDF-LO is
conveyed by the Session Initiation Protocol (SIP). It provides conveyed by the Session Initiation Protocol (SIP). It provides
recommendations for how the SIP location conveyance mechanism should recommendations for how the SIP location conveyance mechanism should
adapt to these ambiguities. adapt to these ambiguities.
Documents standardizing the SIP location conveyance mechanisms will Documents standardizing the SIP location conveyance mechanisms will
be standards-track documents processed according to the usual SIP be standards-track documents processed according to the usual SIP
process. This document is intended primarily to provide the SIP process. This document is intended primarily to provide the SIP
working group with a statement of the consensus of the GEOPRIV working group with a statement of the consensus of the GEOPRIV
working group on this topic. It secondarily provides tutorial working group on this topic. It secondarily provides tutorial
information on the problem space for the general reader. information on the problem space for the general reader.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Core Semantics . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Core Semantics . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Limiting Access . . . . . . . . . . . . . . . . . . . . . 7 3.3. Limiting Access . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Limiting access using public-key encryption . . . . . 7 3.3.1. Limiting Access using Public Key Encryption . . . . . 6
3.3.2. Limiting access using Location-by-Reference . . . . . 8 3.3.2. Limiting Access using Location-by-Reference . . . . . 7
3.3.3. Refraining from including location . . . . . . . . . . 9 3.3.3. Refraining from Including Location Information . . . . 8
3.4. Choosing among the available mechanisms . . . . . . . . . 10 3.4. Choosing Among the Available Mechanisms . . . . . . . . . 8
3.5. Indicating permission to use location-based routing in 3.5. Indicating Permission to Use Location-Based Routing in
SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Behavior of Back-to-Back User Agents . . . . . . . . . . . 11 3.6. Behavior of Back-to-Back User Agents . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Informative References . . . . . . . . . . . . . . . . . . . . 15 7. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
The Presence Information Data Format for Location Objects (PIDF-LO The Presence Information Data Format for Location Objects (PIDF-LO
[4] carries both location information (LI) and policy information set [RFC4119]) carries both location information (LI) and policy
by the Rule Maker, as is stipulated in [3]. The policy carried along information set by the Rule Maker, as is stipulated in [RFC3693].
with LI allows the Rule Maker to restrict, among other things, the The policy carried along with LI allows the Rule Maker to restrict,
duration for which LI will be retained by recipients and the among other things, the duration for which LI will be retained by
redistribution of LI by recipients. recipients and the redistribution of LI by recipients.
The Session Initiation Protocol [2] is one proposed Using Protocol The Session Initiation Protocol [RFC3261] is one proposed Using
for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is
[1]. The common motivation for providing LI in SIP is to allow specified in [I-D.ietf-sip-location-conveyance]. The common
location to be considered in routing the SIP message. One example motivation for providing LI in SIP is to allow location to be
use case would be emergency services, in which the location will be considered in routing the SIP message. One example use case would be
used by dispatchers to direct the response. Another use case might emergency services, in which the location will be used by dispatchers
be providing location to be used by services associated with the SIP to direct the response. Another use case might be providing location
session; a location associated with a call to a taxi service, for to be used by services associated with the SIP session; a location
example, might be used to route to a local franchisee of a national associated with a call to a taxi service, for example, might be used
service and also to route the taxi to pick up the caller. to route to a local franchisee of a national service and also to
route the taxi to pick up the caller.
Some ambiguities have arisen in the interpretation of Rule Maker Some ambiguities have arisen in the interpretation of Rule Maker
policy when PIDF-LO is conveyed by SIP. The following sections policy when PIDF-LO is conveyed by SIP. The following sections
explore the problem and provide a recommendation. explore the problem and provide a recommendation.
2. Problem Statement 2. Problem Statement
The <retransmission-allowed> element of RFC4119 was designed for use The <retransmission-allowed> element of RFC4119 was designed for use
in an environment like that of Section 4 of RFC3693, in which in an environment like that of Section 4 of RFC3693, in which
Location Information (LI) propagates from a Location Generator Location Information (LI) propagates from a Location Generator
through a Location Server to a Location Recipient. In this through a Location Server to a Location Recipient. In this
architecture, it is the responsibility of the Location Server to act architecture, it is the responsibility of the Location Server to act
on the rules (policy) governing access control to LI, which are in on the rules (policy) governing access control to LI, which are in
turn set by the Rule Maker. The most important of these turn set by the Rule Maker. The most important of these
responsibilities is delivering LI to authorized Location Recipients responsibilities is delivering LI to authorized Location Recipients
and denying it to others. Internal to RFC4119-compliant location and denying it to others. Internal to RFC4119-compliant location
objects (LOs) are additional privacy rules which are intended to objects (LOs) are additional privacy rules which are intended to
constrain Location Recipients. These include the <retransmission- constrain Location Recipients. These include the <retransmission-
allowed> element. This element is intended to prevent a allowed> element. This element is intended to prevent a compromise
compromise of privacy when an authorized recipient of LI shares that of privacy when an authorized recipient of LI shares that LI with
LI with third-party entities, principally those who are not third-party entities, principally those who are not authorized by the
authorized by the Rule Maker to receive LI. For example, a user Rule Maker to receive LI. For example, a user might be willing to
might be willing to share their LI with a pizza shop, but they might share their LI with a pizza shop, but they might not want that pizza
not want that pizza shop to sell their LI to a targeted advertising shop to sell their LI to a targeted advertising company that will
company that will contact the user with coupons for a nearby hair contact the user with coupons for a nearby hair salon.
salon.
Bear in mind, however, that <retransmission-allowed> is not intended Bear in mind, however, that <retransmission-allowed> is not intended
to provide any protocol-level mechanism to prevent unauthorized to provide any protocol-level mechanism to prevent unauthorized
parties from learning location through means like eavesdropping. It parties from learning location through means like eavesdropping. It
is merely a way to express the preferences of the Rule Maker to the is merely a way to express the preferences of the Rule Maker to the
LR. If the LR were, for example, legally bound to follow the privacy LR. If the LR were, for example, legally bound to follow the privacy
preferences expressed by Rule Makers, then they might incur liability preferences expressed by Rule Makers, then they might incur liability
of they ignored the <retransmission-allowed> parameter. No further of they ignored the <retransmission-allowed> parameter. No further
privacy protection is assumed to be provided by <retransmission- privacy protection is assumed to be provided by <retransmission-
allowed>. allowed>.
skipping to change at page 7, line 7 skipping to change at page 5, line 43
we understand who the intended LR is in the location-based routing we understand who the intended LR is in the location-based routing
case? Can a UAC have intended for there to be multiple serial LRs in case? Can a UAC have intended for there to be multiple serial LRs in
a transmission? If so, if one LR is authorized to retransmit to a transmission? If so, if one LR is authorized to retransmit to
another LR, how will it know it is not also authorized to transmit LI another LR, how will it know it is not also authorized to transmit LI
to other third parties (i.e., how will the serial LRs know to whom to other third parties (i.e., how will the serial LRs know to whom
they are authorized to retransmit)? How could all of this be they are authorized to retransmit)? How could all of this be
designated? designated?
3. Recommendation 3. Recommendation
The following sections provide a recommendation for how the
<retranmission-allowed> flag should be understood in a SIP
environment. The core semantics of this recommendation represent the
consensus of the GEOPRIV working group. While Section 3.5 proposes a
syntax that might be adopted by the SIP WG to implement these
semantics in its protocol, the actual syntax of SIP is the
responsibility of the SIP WG.
3.1. Goals 3.1. Goals
After extensive discussion in both GEOPRIV and SIP contexts, there After extensive discussion in both GEOPRIV and SIP contexts, there
seems to be consensus that a solution for this problem must enable seems to be consensus that a solution for this problem must enable
location-based routing to work even when the <retransmission-allowed> location-based routing to work even when the <retransmission-allowed>
flag is set to "no". A solution should also give the Rule Maker the flag is set to "no". A solution should also give the Rule Maker the
ability to allow or forbid the use of LI for location-based routing ability to allow or forbid the use of LI for location-based routing
and the ability to allow or forbid the use of LI for the consumption and the ability to allow or forbid the use of LI for the consumption
of the endpoint. of the endpoint.
skipping to change at page 7, line 32 skipping to change at page 6, line 30
considered an authorized recipient of that LI. Because of this considered an authorized recipient of that LI. Because of this
presumption, one SIP element may pass the LI to another even if the presumption, one SIP element may pass the LI to another even if the
LO it contains has <retransmission-allowed> set to "no"; this sees LO it contains has <retransmission-allowed> set to "no"; this sees
the passing of the SIP message as part of the delivery to authorized the passing of the SIP message as part of the delivery to authorized
recipients, rather than as retransmission. SIP entities are still recipients, rather than as retransmission. SIP entities are still
enjoined from passing these messages outside the normal routing to enjoined from passing these messages outside the normal routing to
external entities if <retransmission-allowed> is set to "no", as it external entities if <retransmission-allowed> is set to "no", as it
is the passing to 3rd parties that <retransmission-allowed> is meant is the passing to 3rd parties that <retransmission-allowed> is meant
to control. to control.
This is considerably different from the presumptions of RFC3963, in This architecture is considerably different from the presumptions of
that authorized recipients pass the LO on to other authorized RFC3963, in that authorized recipients pass the LO on to other
recipients, but it seems to be the most sensible mechanism given authorized recipients, but it seems to be the most sensible mechanism
SIP's operation. given SIP's operation.
To maintain the Rule Maker's ability to affect the consumption of To maintain the Rule Maker's ability to affect the consumption of
this information, two different mechanisms may be used to limit the this information, two different mechanisms may be used to limit the
distribution of LI and one may used to limit the sphere in which it distribution of LI and one may used to limit the sphere in which it
may be used; these are discussed below. may be used; these are discussed below.
3.3. Limiting Access 3.3. Limiting Access
3.3.1. Limiting access using public-key encryption 3.3.1. Limiting Access using Public Key Encryption
One way of limiting access to LI is to encrypt the PIDF-LO object in One way of limiting access to LI is to encrypt the PIDF-LO object in
a SIP request. If the originator knows which specific entity on the a SIP request. If the originator knows which specific entity on the
path needs to inspect the LI, and knows a public key for that entity, path needs to inspect the LI, and knows a public key for that entity,
this is a straightforward matter. It is even possible to encrypt this is a straightforward matter. It is even possible to encrypt
multiple instance of PIDF-LO, containing different policies or levels multiple instance of PIDF-LO, containing different policies or levels
of location granularity, in the same SIP request if multiple entities of location granularity, in the same SIP request if multiple entities
along the path need to inspect the location. along the path need to inspect the location.
This is most likely to be effective in cases where the originator This is most likely to be effective in cases where the originator
skipping to change at page 8, line 27 skipping to change at page 7, line 25
encrypted LIs will not be useful in any case where the anticipation encrypted LIs will not be useful in any case where the anticipation
of the originators is not met. of the originators is not met.
An additional problem posed by this approach is that it requires some An additional problem posed by this approach is that it requires some
sort of public key discovery system, which compounds the operational sort of public key discovery system, which compounds the operational
complexity significantly. While this method is included for complexity significantly. While this method is included for
completeness, it is the consensus of the working group that the completeness, it is the consensus of the working group that the
deployment scenarios in which this is appropriate will be relatively deployment scenarios in which this is appropriate will be relatively
few; we do not believe it is an appropriate baseline approach. few; we do not believe it is an appropriate baseline approach.
3.3.2. Limiting access using Location-by-Reference 3.3.2. Limiting Access using Location-by-Reference
Another, more feasible approach is leveraging location by reference. Another, more feasible approach is leveraging location by reference.
When a SIP request conveys a reference, it cannot be properly said to When a SIP request conveys a reference, it cannot be properly said to
be conveying location; location is conveyed upon dereferencing the be conveying location; location is conveyed upon dereferencing the
URI in the question, and the meaning of <retransmission-allowed> must URI in the question, and the meaning of <retransmission-allowed> must
be understood in the context of that conveyance, not the forwarding be understood in the context of that conveyance, not the forwarding
of the SIP request. of the SIP request.
The properties of references, especially the security properties, The properties of references, especially the security properties,
vary significantly depending on the nature and disposition of the vary significantly depending on the nature and disposition of the
skipping to change at page 9, line 35 skipping to change at page 8, line 34
retransmission policy. The cost of the reference itself is of course retransmission policy. The cost of the reference itself is of course
the server that maintains the resource. While not every SIP client the server that maintains the resource. While not every SIP client
has access to an appropriate server for this purpose, the fact that has access to an appropriate server for this purpose, the fact that
PIDF-LO builds on the typical SIP presence service makes this less PIDF-LO builds on the typical SIP presence service makes this less
implausible than it might be. Moreover, the LbyR approach casts the implausible than it might be. Moreover, the LbyR approach casts the
conveyance architecture in a manner familiar from RFC3693, with a conveyance architecture in a manner familiar from RFC3693, with a
Location Server receiving requests from Location Recipients which may Location Server receiving requests from Location Recipients which may
be accepted or denied. This allows the preservation of the original be accepted or denied. This allows the preservation of the original
semantics of <retransmission-allowed>. semantics of <retransmission-allowed>.
3.3.3. Refraining from including location 3.3.3. Refraining from Including Location Information
The most fundamental mechanism for limiting access to location The most fundamental mechanism for limiting access to location
information is simply not including it. While location-based-routing information is simply not including it. While location-based-routing
might conceivably occur in almost any SIP message in the future, might conceivably occur in almost any SIP message in the future,
there is no requirement that location be included in the general case there is no requirement that location be included in the general case
to support it. If it is not included and is required, an appropriate to support it. If it is not included and is required, an appropriate
error indicating the lack may be returned and the choice made to error indicating the lack may be returned and the choice made to
continue communication with the information included. This challenge continue communication with the information included. This challenge
and response will slow the establishment of communication when it is and response will slow the establishment of communication when it is
required, but it is the most basic way to ensure that location required, but it is the most basic way to ensure that location
distribution is limited to the times when it is required for distribution is limited to the times when it is required for
communication to proceed. communication to proceed.
3.4. Choosing among the available mechanisms 3.4. Choosing Among the Available Mechanisms
Refraining from including location is the most appropriate choice for Refraining from including location is the most appropriate choice for
systems that do not wish to reveal location to any party in the SIP systems that do not wish to reveal location to any party in the SIP
path. path.
Location-by-Reference is generally recommended as the most deployable Location-by-Reference is generally recommended as the most deployable
mechanism for limiting access to LI which is passed via a SIP mechanism for limiting access to LI which is passed via a SIP
message. It is significantly easier to deploy than public key message. It is significantly easier to deploy than public key
discovery systems, allows for both whitelists and blacklists, and can discovery systems, allows for both whitelists and blacklists, and can
scale in ways that the inclusion of multiple encrypted bodies cannot. scale in ways that the inclusion of multiple encrypted bodies cannot.
Encryption may be used in a limited set of circumstance where Encryption may be used in a limited set of circumstance where
location-by-value must be used. location-by-value must be used.
3.5. Indicating permission to use location-based routing in SIP 3.5. Indicating Permission to Use Location-Based Routing in SIP
The discussion in 3.3 describes 3 mechanisms for limiting the The discussion in Section 3.3.2 describes 3 mechanisms for limiting
distribution of LI to specific entities. There remains the problem the distribution of LI to specific entities. There remains the
of limiting the use to which LI included by value or by reference may problem of limiting the use to which LI included by value or by
be put. In order to meet the need to limit that use, this document reference may be put. In order to meet the need to limit that use,
recommends the creation of a "Location-Routing-Allowed" header for this document recommends the creation of a syntactical element in SIP
SIP. to carry this information. As an exemplary concrete proposal, we
recommend a "Location-Routing-Allowed" header as described below.
When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is
indicating permission to use the included LI for location-based indicating permission to use the included LI for location-based
routing. When "Location-Routing-Allowed" is set to "No", the routing. When "Location-Routing-Allowed" is set to "No", the
originator is indicating that this use is not permitted. "Location- originator is indicating that this use is not permitted. "Location-
Routing-Allowed" being set to "No" has no protocol-level mechanism Routing-Allowed" being set to "No" has no protocol-level mechanism
for enforcement of this behavior; like the PIDF-LO "retransmission- for enforcement of this behavior; like the PIDF-LO <retransmission-
allowed" being set to "no", it is a way for the Rule Maker to express allowed> being set to "no", it is a way for the Rule Maker to express
a preference to the SIP elements which are LI recipients. It may, a preference to the SIP elements which are LI recipients. It may,
however, present a significant optimization. Where a location-by- however, present a significant optimization. Where a location-by-
reference is included with "Location-Routing-Allowed" set to "No", reference is included with "Location-Routing-Allowed" set to "No",
the SIP elements along the path know that they do not need to attempt the SIP elements along the path know that they do not need to attempt
to dereference the location information; this is significantly faster to dereference the location information; this is significantly faster
than attempting the dereference and being denied at the than attempting the dereference and being denied at the
authentication stage. authentication stage.
We recommend that "Location-Routing-Allowed" be made mandatory-to- We recommend that "Location-Routing-Allowed" be made mandatory-to-
implement for elements complying with [1]. implement for elements complying with [1].
skipping to change at page 11, line 24 skipping to change at page 10, line 21
reference or by value, insert a "Location-Routing-Allowed header if reference or by value, insert a "Location-Routing-Allowed header if
one is not already present. If one is present, it should not be one is not already present. If one is present, it should not be
over-ridden by the SIP element inserting the location. over-ridden by the SIP element inserting the location.
We recommend that any SIP element not the originator of a message and We recommend that any SIP element not the originator of a message and
not inserting a location be enjoined from inserting a "Location- not inserting a location be enjoined from inserting a "Location-
Routing-Allowed" header. Routing-Allowed" header.
3.6. Behavior of Back-to-Back User Agents 3.6. Behavior of Back-to-Back User Agents
Back-to-Back user agents are always a bit tricky, since they function While the behavior of back-to-back user agents (B2BUAs) is outside
in multiple realms. One standard way of approaching their behavior the scope of SIP standardization, there are nevertheless ways that a
is to see them as terminating one flow of information and originating B2BUA might approach conveyed location information and the
a new one. From that perspective, the correct behavior of a B2BUA <retransmission-allowed> flag that will have better results than
receiving LI on one "back" is to treat that as terminating the others. This section documents the consequences of B2BUA behavior
information flow. It can originate a new information flow containing interacting with <retransmission-allowed>.
that LI by value in the other direction only if the PIDF-LO it
contains permits it by using <retransmission-allowed> set to yes. If Typically, B2BUAs are described as terminating one session and
the PIDF-LO it contains is encrypted, it can pass it onward with the originating a new one. From that perspective, a B2BUA receiving LI
understanding that a recipient capable of decrypting it is on one of its "backs" might treat itself as terminating the flow of
authorized. information and thus view itself as a recipient for the purposes of
<retransmission-allowed>. In that case, it should originate a new
information flow containing that LI by value in the other direction
only if the PIDF-LO it receives permitted it (i.e. if
<retransmission-allowed> is set to 'yes'). If the PIDF-LO it
receives is encrypted, it can pass it onward with the understanding
that a recipient capable of decrypting it is authorized; the B2BUA
does not seem to be a recipient in this instance.
Note that this case is also easier to handle using the location-by- Note that this case is also easier to handle using the location-by-
reference model. Since the passing of location-by-reference does not reference model. Since the passing of location-by-reference does not
properly include the location itself, it can pass a location-by- properly include the location itself, it can pass a location-by-
reference pointer in the new direction with the understanding that reference pointer in the new direction with the understanding that
the dereferencing protocol handles the determination of whether those the dereferencing protocol handles the determination of whether those
dereferencing the location are authorized recipients or not. dereferencing the location are authorized recipients or not.
If both sides of a B2BUA's are SIP, we recommend that it copy any If both sides of a B2BUA speak SIP, note that failing to copy any
"Location-Routing-Allowed" header value found in the input flow when "Location-Routing-Allowed" header value found in the input flow when
it re-originates the flow. it re-originates the flow will neglect the policies of the Rule
Maker.
4. IANA Considerations 4. IANA Considerations
This document contains no considerations for the IANA. This memo includes no request to IANA.
5. Security Considerations 5. Security Considerations
The privacy and security implications of distributing location The privacy and security implications of distributing location
information are the fundamental subject of this document. information are the fundamental subject of this document.
6. Acknowledgements 6. Acknowledgements
James Polk provided a series of questions regarding the specifics of James Polk provided a series of questions regarding the specifics of
the Location-Routing-Allowed mechanism, and this resulted in the the Location-Routing-Allowed mechanism, and this resulted in the
recommendations in Section 3.4 recommendations in Section 3.4.
7. Informative References 7. Informative References
[1] Polk, J. and B. Rosen, "Location Conveyance for the Session [I-D.ietf-sip-location-conveyance]
Initiation Protocol", draft-ietf-sip-location-conveyance-10 Polk, J. and B. Rosen, "Location Conveyance for the
(work in progress), February 2008. Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress),
September 2008.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[4] Peterson, J., "A Presence-based GEOPRIV Location Object Format", [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
RFC 4119, December 2005. Format", RFC 4119, December 2005.
Authors' Addresses Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Email: hardie@qualcomm.com
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St., Suite 570
Concord, CA 94520
US
Phone: +1 925 363-8720
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
Ted Hardie
Qualcomm
John B. Morris, Jr. Email: hardie@qualcomm.com
Center for Democracy and Technology
1634 I Street NW John Morris
Suite 1100 CDT
Washington, DC 20006
US
Email: jmorris@cdt.org Email: jmorris@cdt.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 31 change blocks. 
108 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/