idnits 2.17.1 draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 358. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 172 has weird spacing: '...dDevice xmlns...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2007) is 6012 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2818' is defined on line 252, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-02 == Outdated reference: A later version (-01) exists of draft-winterbottom-geopriv-lis2lis-req-00 == Outdated reference: A later version (-10) exists of draft-winterbottom-geopriv-held-identity-extensions-03 == Outdated reference: A later version (-06) exists of draft-thomson-geopriv-held-measurements-00 == Outdated reference: A later version (-05) exists of draft-thomson-geopriv-held-beep-00 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-05 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: Best Current Andrew Corporation 5 Practice November 9, 2007 6 Expires: May 12, 2008 8 Using HELD for Inter-LIS Communication 9 draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 12, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes how HELD can be used to support LIS to LIS 43 communication. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6 51 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 54 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 55 8.1. Normative references . . . . . . . . . . . . . . . . . . . 12 56 8.2. Informative references . . . . . . . . . . . . . . . . . . 12 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 58 Intellectual Property and Copyright Statements . . . . . . . . . . 15 60 1. Introduction 62 The LIS to LIS communication requirements 63 [I-D.winterbottom-geopriv-lis2lis-req] describe the need in some 64 network environements for one LIS to consult another LIS in order to 65 determine the location of a Device. This document describes how HELD 66 [I-D.ietf-geopriv-http-location-delivery] in conjunction with the 67 HELD identity extensions 68 [I-D.winterbottom-geopriv-held-identity-extensions] and the HELD 69 measurements specification [I-D.thomson-geopriv-held-measurements] 70 can be used to satisfy these requirements. No new schema is 71 introduced by this document, recipes using existing specifications 72 are described. 74 2. Terminology 76 The key conventions and terminology used in this document are defined 77 as follows: 79 This document reuses the terms Target, as defined in [RFC3693]. 81 This document uses the term Location Information Server, LIS, is used 82 as defined in [I-D.ietf-geopriv-l7-lcp-ps]. 84 Basic terms from the HELD specification 85 [I-D.ietf-geopriv-http-location-delivery] are also reused. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Overview 93 The network scenario described in 94 [I-D.winterbottom-geopriv-lis2lis-req] shows that in some 95 environments the LIS publically associated with a Device cannot, on 96 its own, determine the location of the Device. HELD provides a 97 specification allowing a Device to obtain location information from a 98 Location Information Server (LIS). This specification extends HELD 99 by chaining a location request from the publically accessible LIS to 100 a LIS controlled by a regional access provider. The publically 101 accessible LIS can also add measured and identity parameters relating 102 to the Device in the HELD locationRequest made to the access provider 103 LIS. Resuing HELD in this manner reduces the number of protocols 104 that need to be supported on a LIS, it simplfies development, reduces 105 complexity, and improves interoperability. 107 4. Detailed Description 109 In a typical environment using HELD, the Target discovers the LIS 110 using one of the methods described in 111 [I-D.thomson-geopriv-lis-discovery], and makes a request for location 112 information. The ISP LIS receives the location request from the 113 Target, adds additional information, and then sends the location 114 request on to the regional access provider LIS. The regional access 115 provider LIS uses the extra information provided in the ISP LIS to 116 determine the location of the Device and provide the PIDF-LO 117 [RFC4119] in the requested form. 119 The ISP LIS will, in many cases creates the identity used in the 120 "pres" field of the PIDF-LO. This value needs to be conveyed from 121 the ISP LIS to the regional access provider LIS. HELD can convey 122 this value using a URI identity extension as described in 123 [I-D.winterbottom-geopriv-held-identity-extensions]. 125 The ISP LIS may need to provide Device network attachment 126 information, in the form of measurements, to the regional access 127 provider LIS to aid it in determing the Device's location. A 128 comprehensive set of measurements and how they are used is provided 129 in [I-D.thomson-geopriv-held-measurements]. HELD supports the 130 inclusion of these additional elements without modification. 132 The ISP LIS should not send a request for a location URI to the 133 regional access provider LIS. This is because the regional access 134 provider LIS is, in most cases, invisible to entities other than the 135 ISP LIS. A location URI contains the hostname of the LIS that will 136 service a location request, which is the ISP LIS and not the regional 137 access provider LIS. Consequently only the ISP LIS should create 138 location URIs for the Device. A regional access provider LIS 139 receiving a request for a location URI from an ISP LIS should respond 140 with a "cannotProvideLiType" error. 142 The ISP LIS should pass all elements included in the Device's 143 location request to the regional access provider LIS, with the 144 exception of a request for a location URI which was described in the 145 previous paragraph. This behaviour ensures that any new options made 146 available to the LIS through HELD can be supported without 147 necessarily requiring changes to the ISP LIS. 149 The ISP LIS should provide usage in any returned location object that 150 match the user's desired settings, or in the absence of these, the 151 default settings for and 152 as applied by the ISP LIS. 154 Basic HELD is provided with an HTTP binding, which is suitable for 155 the application of a Device requesting its own location. Where a 156 nailed up connection between two entities and continual transaction 157 streaming is required, HTTP may be less appropriate. In this 158 configuration an alternative transport, such as BEEP 159 [I-D.thomson-geopriv-held-beep], may be used. 161 5. Examples 163 In this example a DSL service is provided with an L2TP tunnel forming 164 the link between the BRAS in the regional access provider's network, 165 and the NAS in the ISP. The Device has requested a civic location. 166 The resulting location request sent from the ISP LIS to the regional 167 access provider LIS is shown in Figure 1. 169 171 civic 172 173 pres:3sijsskcknckj@ls.example.com 174 175 176 177 178 192.0.2.10 179 192.0.2.61 180 528 181 182 183 184 186 Figure 1: LIS to LIS Location Request with L2TP Measurements 188 The regional access provider LIS would use the L2TP tunnel 189 information to establish the location of the Device. It would then 190 create a PIDF-LO using the URI specified as a as the 191 presentity value. The resulting location response from the access 192 provider LIS to the ISP LIS may look something similar to Figure 2. 193 On receiving this response the ISP LIS will need to add the usage 194 rules specified by the Device or use local defaults if no Device 195 instructions are available. 197 198 200 201 202 203 204 207 AU 208 NSW 209 Wollongong 210 Gwynneville 211 Northfield Avenue 212 University of Wollongong 213 2 214 Andrew Corporation 215 2500 216 39 217 WS-183 218 U40 219 220 221 222 223 224 2007-10-31T03:42:28+00:00 225 226 227 229 Figure 2: Regional Access Provider LIS Response 231 6. Security Considerations 233 A strong trust relationship needs to exist between the ISP and the 234 regional access provider in order for this type of access network to 235 operate successfully. Since this document describes the exchange of 236 Device location information between two trusted parties it does not 237 mandate the use of any specific crypto techniques but recommends the 238 use of TLS with client-side and server-side certificates for 239 authentication. 241 7. IANA Considerations 243 There are no IANA considerations for this document. 245 8. References 247 8.1. Normative references 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 254 [I-D.ietf-geopriv-http-location-delivery] 255 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 256 "HTTP Enabled Location Delivery (HELD)", 257 draft-ietf-geopriv-http-location-delivery-02 (work in 258 progress), September 2007. 260 [I-D.winterbottom-geopriv-lis2lis-req] 261 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 262 Requirements", draft-winterbottom-geopriv-lis2lis-req-00 263 (work in progress), June 2007. 265 [I-D.winterbottom-geopriv-held-identity-extensions] 266 Winterbottom, J. and M. Thomson, "HELD Device identity 267 Extensions", 268 draft-winterbottom-geopriv-held-identity-extensions-03 269 (work in progress), October 2007. 271 [I-D.thomson-geopriv-held-measurements] 272 Thomson, M. and J. Winterbottom, "Using Device-provided 273 Location Measurements in HELD", 274 draft-thomson-geopriv-held-measurements-00 (work in 275 progress), October 2007. 277 8.2. Informative references 279 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 280 Format", RFC 4119, December 2005. 282 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 283 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 285 [I-D.thomson-geopriv-held-beep] 286 Thomson, M. and J. Winterbottom, "A BEEP Binding for the 287 HELD Protocol", draft-thomson-geopriv-held-beep-00 (work 288 in progress), February 2007. 290 [I-D.thomson-geopriv-lis-discovery] 291 Thomson, M. and J. Winterbottom, "Discovering the Local 292 Location Information Server (LIS)", 293 draft-thomson-geopriv-lis-discovery-03 (work in progress), 294 September 2007. 296 [I-D.ietf-geopriv-l7-lcp-ps] 297 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 298 Location Configuration Protocol; Problem Statement and 299 Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in 300 progress), September 2007. 302 Authors' Addresses 304 James Winterbottom 305 Andrew Corporation 306 PO Box U40 307 University of Wollongong, NSW 2500 308 AU 310 Email: james.winterbottom@andrew.com 312 Martin Thomson 313 Andrew Corporation 314 PO Box U40 315 University of Wollongong, NSW 2500 316 AU 318 Email: martin.thomson@andrew.com 320 Full Copyright Statement 322 Copyright (C) The IETF Trust (2007). 324 This document is subject to the rights, licenses and restrictions 325 contained in BCP 78, and except as set forth therein, the authors 326 retain all their rights. 328 This document and the information contained herein are provided on an 329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 331 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 332 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 333 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 Intellectual Property 338 The IETF takes no position regarding the validity or scope of any 339 Intellectual Property Rights or other rights that might be claimed to 340 pertain to the implementation or use of the technology described in 341 this document or the extent to which any license under such rights 342 might or might not be available; nor does it represent that it has 343 made any independent effort to identify any such rights. Information 344 on the procedures with respect to rights in RFC documents can be 345 found in BCP 78 and BCP 79. 347 Copies of IPR disclosures made to the IETF Secretariat and any 348 assurances of licenses to be made available, or the result of an 349 attempt made to obtain a general license or permission for the use of 350 such proprietary rights by implementers or users of this 351 specification can be obtained from the IETF on-line IPR repository at 352 http://www.ietf.org/ipr. 354 The IETF invites any interested party to bring to its attention any 355 copyrights, patents or patent applications, or other proprietary 356 rights that may cover technology that may be required to implement 357 this standard. Please address the information to the IETF at 358 ietf-ipr@ietf.org. 360 Acknowledgment 362 Funding for the RFC Editor function is provided by the IETF 363 Administrative Support Activity (IASA).