idnits 2.17.00 (12 Aug 2021) /tmp/idnits43397/draft-peterson-geopriv-retransmission-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 525. 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 -- 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 (February 15, 2008) is 5202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 446, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar 4 Intended status: Informational T. Hardie 5 Expires: August 18, 2008 Qualcomm 6 J. Morris 7 CDT 8 February 15, 2008 10 Implications of for SIP Location Conveyance 11 draft-peterson-geopriv-retransmission-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 18, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document explores an ambiguity in the interpretation of the 45 element of the Presence Information Data 46 Format for Location Objects (PIDF-LO) in cases where PIDF-LO is 47 conveyed by the Session Initiation Protocol (SIP). It provides 48 recommendations for how the SIP location conveyance mechanism should 49 adapt to these ambiguities. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. Indicating Permission . . . . . . . . . . . . . . . . . . 5 57 3.2. Withholding Location . . . . . . . . . . . . . . . . . . . 7 58 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 8. Informational References . . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 64 Intellectual Property and Copyright Statements . . . . . . . . . . 12 66 1. Introduction 68 The Presence Information Data Format for Location Objects (PIDF-LO 69 [4]) carries both location information (LI) and policy information 70 set by the Rule Maker, as is stipulated in RFC3693 [3]. The policy 71 carried along with LI allows the Rule Maker to restrict, among other 72 things, the duration for which LI will be retained by recipients and 73 the redistribution of LI by recipients. 75 The Session Initiation Protocol (RFC3261 [1]) is one proposed Using 76 Protocol (see RFC3693) for PIDF-LO. The conveyance of PIDF-LO within 77 SIP is specified in [5]. The common motivation for providing LI in 78 SIP is to allow location-based personal communications services. One 79 example would be emergency services; another would be fast food 80 delivery. 82 Some ambiguities have arisen in the interpretation of Rule Maker 83 policy when PIDF-LO is conveyed by SIP. The following sections 84 explore the problem and possible solutions before providing a 85 recommendation. 87 2. Problem Statement 89 The element of RFC4119 was designed for use 90 in an environment like that of Section 4 of RFC3693, in which 91 Location Information (LI) propagates from a Location Generator 92 through a Location Server to a Location Recipient. In this 93 architecture, it is the responsibility of the Location Server to act 94 on the rules (policy) governing access control to LI, which are in 95 turn set by the Rule Maker. The most important of these 96 responsibilities is delivering LI to authorized Location Recipients 97 and denying it to others. Internal to RFC4119-compliant location 98 objects (LOs) are additional privacy rules which are intended to 99 constrain Location Recipients. These include the element. This element is intended to prevent a compromise 101 of privacy when an authorized recipient of LI shares that LI with 102 third-party entities, principally those who are not authorized by the 103 Rule Maker to receive LI. For example, a user might be willing to 104 share their LI with a pizza shop, but they might not want that pizza 105 shop to sell their LI to a targeted advertising company that will 106 contact the user with coupons for a nearby hair salon. 108 Bear in mind, however, that is not intended 109 to provide any protocol-level mechanism to prevent unauthorized 110 parties from learning location through means like eavesdropping. It 111 is merely a way to express the preferences of the Rule Maker to the 112 LR. If the LR were, for example, legally bound to follow the privacy 113 preferences expressed by Rule Makers, then they might incur liability 114 of they ignored the parameter. No further 115 privacy protection is assumed to be provided by . 118 There is a use case for LI that involves embedding it in a SIP 119 request that will potentially traverse multiple SIP intermediaries 120 before arriving at a UAS. In this use case, one or more 121 intermediaries may inspect the LI in order to make a SIP routing 122 decision; we will hereafter refer to this as location-based routing. 123 Common examples would include emergency services and other more 124 mundane cases where the originator of a SIP request wants to reach a 125 service in proximity to a particular geographic location, such as 126 contacting a nearby pizza shop. In both such cases the UAC may 127 intend for selected intermediaries and the UAS to have access to the 128 LI. In the pizza case, for instance, the UAC shares an address both 129 for location-based routing and additionally so that the pizza shop 130 reached by that routing has the address to which a pizza should be 131 sent. 133 This location-based routing use case for LI has a number of important 134 disconnects from the RFC3693 model. Unlike the RFC3693 model, there 135 is no LS designating to which specific entities LI will be sent. 136 There may be multiple intermediaries between the UAC and UAS, some of 137 which need or want to inspect LI (which would seem to qualify them as 138 LRs) and some of them will not. While SIP proxy servers generally 139 are not RFC4119-aware and do not need to inspect SIP request bodies 140 in order to perform their function, nothing however precludes proxy 141 servers inspecting or logging any SIP message bodies, including LI. 142 Furthermore, it is very difficult for the UAC to anticipate which 143 intermediaries and which eventual UAS a SIP request might reach. 145 This architecture is further complicated by the possibility of 146 sending location information by-reference, that is, placing a URL 147 where LI can be retrieved in SIP requests instead of a by-value 148 PIDF-LO body - depending on the qualities of a reference, further 149 authorization checks may be performed before LI is retrieved, LI may 150 be customized depending on who is asking, and so forth. The 151 conveyance of a reference may have very different privacy properties 152 than conveying a PIDF-LO body by-value in a SIP request. 154 In these location-based routing cases, a number of questions and 155 concerns arise when is set to "no". The 156 core concern is "to whom does apply in 157 location-based routing?" More specifically: 158 Is any entity that reads LI bound by If 159 so, does that mean a proxy that performs location-based routing is 160 unable to forward a request and complete a SIP call if 161 is not to "no" unless they strip location 162 out of the message? This interpretation is fairly problematic, 163 and a solution is required to allow location-based routing to take 164 place. 165 By forwarding a request at all, is a SIP proxy violating RFC4119? 166 Of course, not all proxies understand RFC4119, but is any entity 167 that potentially could read LI under an obligation to read it if 168 only to learn that it is not authorized to retransmit it? Is 169 there a need for SIP-level indications regarding retransmission 170 for the benefit of entities that do not understand 4119? 171 If the UAC cannot anticipate who may receive a SIP request, how do 172 we understand who the intended LR is in the location-based routing 173 case? Can a UAC intended for there to be multiple serial LRs in a 174 transmission? If so, if one LR is authorized to retransmit to 175 another LR, how will it know it is not also authorized to transmit 176 LI to other third parties (i.e., how will the serial LRs know to 177 whom they are authorized to retransmit)? How could all of this be 178 designated? 180 3. Solution Space 182 At a high level, a solution for this problem would enable location- 183 based routing to work even when the flag is 184 set to "no". Ideally, it would give the Rule Maker responsible for 185 LO policy the ability to allow or forbid the use of LI for location- 186 based routing, and similarly allow or forbid the use of LI for the 187 consumption of the endpoint. 189 It is important to note that whatever the solution turns out to be, 190 solving this problem does not obviate the need to explain the meaning 191 of "no" in the absence of the solution. 192 This work cannot be complete without an account of how 193 is to be understood. 195 3.1. Indicating Permission 197 A SIP message conveying location information could contain some sort 198 of indication that allows location-based routing, or more 199 specifically specifies what entity or entities are intended to 200 consume the LI. This admits of varying degrees of specificity: a 201 binary indicator might say only whether or not routing is allowed, a 202 more complex indicator might allow and/or disallow both routing and 203 consumption by endpoints, or a very specific indicator might 204 designate (by hostname, for example) a list of exactly which entities 205 on the SIP signaling path are intended to inspect PIDF-LO. 207 In order for indicators with a great deal of specificity to serve 208 their purpose, the sender of SIP requests must be able to anticipate 209 the path and ultimate destination of messages. In most operational 210 environments this is a more complicated matter than one might think. 211 The manner in which proxy servers make forwarding decisions is 212 unpredictable to the originating UAC, as are any registrations that 213 might be associated with the destination AoR, which might point to 214 unexpected endpoints or new AoRs. Thus, solutions along the lines of 215 specifying an exact list of hosts that a request will visit have very 216 limited applicability. 218 It may even be difficult for the originator of a SIP request to 219 anticipate whether an intermediary or endpoint will need to inspect 220 LI to process a request. In sending a request to 221 sip:orders@pizzahut.example.com, for instance, the UAC cannot 222 anticipate whether pizzahut.example.com uses location-based routing 223 to direct requests to particular retail outlets, or whether the 224 location information is consumed by a centralized monolithic endpoint 225 that dispatches orders in some manner outside the scope of SIP and 226 PIDF-LO. That much said, a binary indicator used to authorize 227 location-based routing (something like "routing=yes") would at least 228 serve to allow location-based routing to occur when is set to "no". 231 Placing the indicator in the Location header has the advantage that a 232 recipient need not inspect the PIDF-LO body in order to learn whether 233 or not they are supposed to inspect it. Parsing an XML body also 234 entails a computational expense that may be burdensome for an 235 intermediary processing large numbers of messages, especially in 236 cases where the parsing yields nothing more than a stop sign. 238 Placing the indicator within the PIDF-LO object has the advantage of 239 binding the indicator to the other policy elements in PIDF-LO. Were 240 the indicator to appear in a SIP header, it would be unclear who set 241 the indicator and what the relationship of that entity might be to 242 the Rule Maker. Furthermore, were the PIDF-LO object in the course 243 of its routing ever to leave the scope of SIP conveyance (say, 244 hitting a gateway to another protocol like Jabber), the indicator 245 would be retained without the need for any special intelligence on 246 the part of the gateway. 248 Regardless of where the indicator is staged, it can do nothing but 249 indicate - it will not prevent any entity from inspecting LI out of 250 malice or incompetence. Of course, the same is true of the 251 element itself. The indicator can serve no 252 other purpose than to express the policy of the originator (hopefully 253 the Rule Maker), and in turn to provide grounds for liability when 254 these policies are violated. 256 3.2. Withholding Location 258 The originator of a SIP request can also withhold LI from particular 259 elements in the signaling stream and reveal it to others. In this 260 manner, the Rule Maker can guarantee that the LI will only be reveal 261 to appropriate recipients, and all such recipients will be understood 262 to be constrained by the of PIDF-LO. Since 263 the Rule Maker specifically authorized each entity capable of 264 inspecting the LI, forwarding the SIP request in this case does not 265 constitute "retransmission". 267 One manner of accomplishing this is to encrypt the PIDF-LO object in 268 a SIP request. If the originator knows which specific entity on the 269 path needs to inspect the LI, and knows a public key for that entity, 270 this is a straightforward matter. It is even possible to encrypt 271 multiple instance of PIDF-LO, containing different policies or levels 272 of location granularity, in the same SIP request if multiple entities 273 along the path need to inspect the location. However, for the much 274 the same reason as the very specific (list of hosts) indicator above 275 is problematic, this is also more or less useless in most practical 276 deployments. Not only is anticipating the intermediaries or 277 endpoints that a request will visit prohibitively difficult, but this 278 approach also requires some sort of public key discovery system which 279 compounds the operational complexity significantly. In some very 280 specific environments this might have some applicability, but they 281 would be rare. 283 Another, more feasible approach is leveraging location by reference. 284 When a SIP request conveys a reference, it cannot be properly said to 285 be conveying location; location is conveyed upon dereferencing the 286 URI in the question, and the meaning of must 287 be understood in the context of that conveyance, not the forwarding 288 of the SIP request. 290 A recent study [Henning's types-of-LbyR] has pointed out that the 291 properties of references, especially the security properties, vary 292 significantly depending on the nature and disposition of the resource 293 indicated. Clearly, if the referenced PIDF-LO is available, in the 294 same form, to any entity along the SIP signaling path that requests 295 it, then inserting a reference has no advantages over inserting LI by 296 value (and introduces wasteful complexity). However, if the Rule 297 Maker influences the results of the dereferencing process, including 298 determining who can receive LI at what degree of granularity and what 299 policies are bound with the LI, 301 It might superficially appear that this suffers from the same 302 problems as the encryption approach, since the Rule Maker must 303 anticipate a set of entities who are authorized to receive location 304 information. The difference is that this set does not need to be 305 communicated in the SIP request in order for authorization decisions 306 to be made. There is a world of difference between managing a 307 whitelist of a thousand parties that might ask for LI and sending a 308 SIP request containing a thousand differently-encrypted adumbrations 309 on LI - the former is commonplace and the latter is impossible. 310 Additionally, some Rule Maker policies might not even require the 311 establishment of an exhaustive whitelist. For example, it may be 312 that there exists a finite set of commercial requestors that the Rule 313 Maker would like to block, in a manner similar to the way ad-blockers 314 operate in modern web browsers. 316 In any system where one makes an authorization decision, a certain 317 cost in authentication must be paid - the greater the assurance the 318 greater the cost. The precise cost will of course depend on the URI 319 scheme of the reference. For SIP, Digest has a low computational 320 cost but requires pre-established keys, which limits applicability. 321 RFC4474 Identity does not require any pre-association, but it does 322 make signaling more heavyweight and requires the deployment of 323 additional features in the network, including a web-like PKI. 325 But even if no authentication takes place, in the LbyR case the 326 meaning of is unambiguous - each entity to 327 which LI is conveyed in the dereference process is bound by the 328 retransmission policy. The cost of the reference itself is of course 329 the server that maintains the resource. While not every SIP client 330 has access to an appropriate server for this purpose, the fact that 331 PIDF-LO builds on the typical SIP presence service makes this less 332 implausible than it might be. Moreover, the LbyR approach casts the 333 conveyance architecture in a manner familiar from RFC3693, with a 334 Location Server receiving requests from Location Recipients which may 335 be accepted or denied. This allows the preservation of the original 336 semantics of . 338 4. Analysis 340 Regardless of how permission for location-based routing is granted, 341 the meaning of with a value of "no" in a 342 PIDF-LO body conveyed in a SIP request must be unambiguous for all 343 endpoints and intermediaries that process the message. Since even 344 location-aware intermediaries might perform a baseline SIP forwarding 345 function without inspecting LI, and location-unaware intermediaries 346 can do nothing but, it is clear that SIP messages with a flag of 347 equal to "no" can and will be forwarded by 348 SIP intermediaries. 350 Leaving aside for the moment the question of LI in particular, and 351 instead considering the matter purely from a SIP perspective, when a 352 UAC sends a SIP request with a body, SIP permits any intermediaries 353 and the eventual endpoint recipient to inspect the body, and places 354 little constraints on how intermediaries arrive at a forwarding 355 decision. In other words, when a UAC sends a request, it is 356 implicitly allowing set of entities to receive that message body, a 357 set whose contents the UAC cannot anticipate in typical SIP 358 environments. Consequently, for the purposes of SIP as a conveyance 359 protocol, it would not be unreasonable to proceed as if each 360 location-aware entity in the routeset of a SIP request is an RFC3693 361 Location Recipient, and as such each is bound by as if the LG had shared this information with them 363 bilaterally, regardless of what actions they take as they process SIP 364 requests. 366 This approach has the desirable property that it does not alter the 367 RFC4119 semantics of . It does however 368 require some additional work to make this understanding of SIP 369 location conveyance meet the privacy goals of RFC3693. Consider, for 370 example, that an unanticipated SIP intermediary which is not 371 location-aware might log SIP requests, body and all, enabling parties 372 interested in tracking location information to data mine its logs 373 later. In any system of intermediaries whose behavior cannot be 374 predicted, these sorts of scenarios are a potential downside. 376 The simplest way to mitigate this risk is by withholding LI. For the 377 many reasons described in the previous section, encryption is not a 378 feasible approach to this. However, a privacy-conscious UAC can send 379 LI by-reference in SIP requests. The service that manages requests 380 for LI (an RFC3693 LS) can then use whatever access controls it sees 381 fit to ensure that LI is only shared with appropriate parties. A SIP 382 intermediary which logged all requests would in this instance merely 383 log a URI rather than a copy of the LI. 385 These risks are not always a primacy concern for UACs, however, and 386 when a UAC cannot or does not wish to publish its location to an LS, 387 it can avail itself of the 'routing-permitted' indicator to express 388 the intended usage of location information. If 'routing-permitted' 389 is set to "yes", a location-aware intermediary knows that the LI so 390 designated is likely to be useful for routing, and that it is worth 391 the trouble to run any routing algorithm. If it is set to "no", then 392 a location-aware intermediary knows not to invoke any routing 393 algorithm - the LI might not be even be useful for making a routing 394 decision in this case. 396 Where location by-reference is preferred, a location-aware 397 intermediary does not want to incur the costs of looking up the 398 reference URI needlessly. If LI is not intended for use by 399 intermediaries, and dereferencing a URI conveyed within SIP would 400 only lead to the denial of the request, the UAC could set the 401 'routing-permitted' indicator in the SIP request to "no". This would 402 let any location-aware intermediary know that it needn't even bother 403 to try to dereference the URI. This use of the indicator argues 404 strongly for making it a SIP-layer indicator (a part of the Location 405 header) rather than a new element of PIDF-LO. Although in this case 406 it is not possible to provide a common integrity protection over the 407 'routing-permitted' indicator and the remainder of policies set by 408 the Rule Maker, the value of tampering with 'routing-permitted' seems 409 low; it will not result in privacy leaks, in any event, since privacy 410 can be managed with greater granularity by withholding LI. 412 In summary, both the strategies of indicating permission and 413 withholding LI are viable, and in fact compatible. 415 5. Recommendation 417 This document recommends that the "recipient" parameter in the SIP 418 location conveyance proposal ([5]) by replaced by a parameter called 419 "routing-permitted". This parameter accepts only a binary value of 420 "yes" or "no". The default value shall be "no". 422 The current text in the SIP location conveyance proposal on privacy, 423 in the first paragraph of Section 5, considers encryption as a means 424 of providing access control for PIDF-LO. For the reasons mentioned 425 in Section 3, encryption is not an optimal means of withholding 426 location information. The relevant text in Section 4.2, 5 and 7 of 427 the SIP location conveyance proposals should instead reference or 428 include the discussion in this document. 430 6. IANA Considerations 432 This document contains no considerations for the IANA. 434 7. Security Considerations 436 The privacy and security implications of distributing location 437 information are the fundamental subject of this document. 439 8. Informational References 441 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 442 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 444 Session Initiation Protocol", RFC 3261, June 2002. 446 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 447 levels", RFC 2119, March 1997. 449 [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 450 Polk, "Geopriv Requirements", RFC 3693, February 2004. 452 [4] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 453 RFC 4119, December 2005. 455 [5] Polk, J. and B. Rosen, "Location Conveyance for the Session 456 Initiation Protocol", draft-ietf-sip-location-conveyance-09 457 (work in progress), November 2007. 459 Authors' Addresses 461 Jon Peterson 462 NeuStar, Inc. 463 1800 Sutter St 464 Suite 570 465 Concord, CA 94520 466 USA 468 Phone: +1 925/363-8720 469 Email: jon.peterson@neustar.biz 470 URI: http://www.neustar.biz/ 472 Ted Hardie 473 Qualcomm, Inc. 475 Email: hardie@qualcomm.com 477 John B. Morris, Jr. 478 Center for Democracy and Technology 479 1634 I Street NW 480 Suite 1100 481 Washington, DC 20006 482 USA 484 Email: jmorris@cdt.org 485 URI: http://www.cdt.org 487 Full Copyright Statement 489 Copyright (C) The IETF Trust (2008). 491 This document is subject to the rights, licenses and restrictions 492 contained in BCP 78, and except as set forth therein, the authors 493 retain all their rights. 495 This document and the information contained herein are provided on an 496 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 497 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 498 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 499 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 500 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 501 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 503 Intellectual Property 505 The IETF takes no position regarding the validity or scope of any 506 Intellectual Property Rights or other rights that might be claimed to 507 pertain to the implementation or use of the technology described in 508 this document or the extent to which any license under such rights 509 might or might not be available; nor does it represent that it has 510 made any independent effort to identify any such rights. Information 511 on the procedures with respect to rights in RFC documents can be 512 found in BCP 78 and BCP 79. 514 Copies of IPR disclosures made to the IETF Secretariat and any 515 assurances of licenses to be made available, or the result of an 516 attempt made to obtain a general license or permission for the use of 517 such proprietary rights by implementers or users of this 518 specification can be obtained from the IETF on-line IPR repository at 519 http://www.ietf.org/ipr. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights that may cover technology that may be required to implement 524 this standard. Please address the information to the IETF at 525 ietf-ipr@ietf.org. 527 Acknowledgment 529 Funding for the RFC Editor function is provided by the IETF 530 Administrative Support Activity (IASA).