idnits 2.17.1 draft-ietf-geopriv-sip-lo-retransmission-01.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 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. 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 (October 26, 2008) is 5660 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 398 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-10 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational T. Hardie 5 Expires: April 29, 2009 Qualcomm 6 J. Morris 7 CDT 8 October 26, 2008 10 Implications of 'retransmission-allowed' for SIP Location Conveyance 11 draft-ietf-geopriv-sip-lo-retransmission-01 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 April 29, 2009. 38 Abstract 40 This document explores an ambiguity in the interpretation of the 41 element of the Presence Information Data 42 Format for Location Objects (PIDF-LO) in cases where PIDF-LO is 43 conveyed by the Session Initiation Protocol (SIP). It provides 44 recommendations for how the SIP location conveyance mechanism should 45 adapt to these ambiguities. 47 Documents standardizing the SIP location conveyance mechanisms will 48 be standards-track documents processed according to the usual SIP 49 process. This document is intended primarily to provide the SIP 50 working group with a statement of the consensus of the GEOPRIV 51 working group on this topic. It secondarily provides tutorial 52 information on the problem space for the general reader. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Core Semantics . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Limiting Access . . . . . . . . . . . . . . . . . . . . . 6 62 3.3.1. Limiting Access using Public Key Encryption . . . . . 6 63 3.3.2. Limiting Access using Location-by-Reference . . . . . 7 64 3.3.3. Refraining from Including Location Information . . . . 8 65 3.4. Choosing Among the Available Mechanisms . . . . . . . . . 8 66 3.5. Indicating Permission to Use Location-Based Routing in 67 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6. Behavior of Back-to-Back User Agents . . . . . . . . . . . 10 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 13 76 1. Introduction 78 The Presence Information Data Format for Location Objects (PIDF-LO 79 [RFC4119]) carries both location information (LI) and policy 80 information set by the Rule Maker, as is stipulated in [RFC3693]. 81 The policy carried along with LI allows the Rule Maker to restrict, 82 among other things, the duration for which LI will be retained by 83 recipients and the redistribution of LI by recipients. 85 The Session Initiation Protocol [RFC3261] is one proposed Using 86 Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is 87 specified in [I-D.ietf-sip-location-conveyance]. The common 88 motivation for providing LI in SIP is to allow location to be 89 considered in routing the SIP message. One example use case would be 90 emergency services, in which the location will be used by dispatchers 91 to direct the response. Another use case might be providing location 92 to be used by services associated with the SIP session; a location 93 associated with a call to a taxi service, for example, might be used 94 to route to a local franchisee of a national service and also to 95 route the taxi to pick up the caller. 97 Some ambiguities have arisen in the interpretation of Rule Maker 98 policy when PIDF-LO is conveyed by SIP. The following sections 99 explore the problem and provide a recommendation. 101 2. Problem Statement 103 The element of RFC4119 was designed for use 104 in an environment like that of Section 4 of RFC3693, in which 105 Location Information (LI) propagates from a Location Generator 106 through a Location Server to a Location Recipient. In this 107 architecture, it is the responsibility of the Location Server to act 108 on the rules (policy) governing access control to LI, which are in 109 turn set by the Rule Maker. The most important of these 110 responsibilities is delivering LI to authorized Location Recipients 111 and denying it to others. Internal to RFC4119-compliant location 112 objects (LOs) are additional privacy rules which are intended to 113 constrain Location Recipients. These include the element. This element is intended to prevent a compromise 115 of privacy when an authorized recipient of LI shares that LI with 116 third-party entities, principally those who are not authorized by the 117 Rule Maker to receive LI. For example, a user might be willing to 118 share their LI with a pizza shop, but they might not want that pizza 119 shop to sell their LI to a targeted advertising company that will 120 contact the user with coupons for a nearby hair salon. 122 Bear in mind, however, that is not intended 123 to provide any protocol-level mechanism to prevent unauthorized 124 parties from learning location through means like eavesdropping. It 125 is merely a way to express the preferences of the Rule Maker to the 126 LR. If the LR were, for example, legally bound to follow the privacy 127 preferences expressed by Rule Makers, then they might incur liability 128 of they ignored the parameter. No further 129 privacy protection is assumed to be provided by . 132 There is a use case for LI that involves embedding it in a SIP 133 request that will potentially traverse multiple SIP intermediaries 134 before arriving at a UAS. In this use case, one or more 135 intermediaries might inspect the LI in order to make a SIP routing 136 decision; we will hereafter refer to this as location-based routing. 137 Common examples could include emergency services and other more 138 mundane cases where the originator of a SIP request wants to reach a 139 service in proximity to a particular geographic location, such as 140 contacting a nearby pizza shop. In both such cases the UAC may 141 intend for selected intermediaries and the UAS to have access to the 142 LI. In the pizza case, for instance, the UAC shares an address both 143 for location-based routing and additionally so that the pizza shop 144 reached by that routing has the address to which a pizza should be 145 sent. 147 This location-based routing use case for LI has a number of important 148 disconnects from the RFC3693 model. Unlike the RFC3693 model, there 149 is no LS designating to which specific entities LI will be sent. 150 There may be multiple intermediaries between the UAC and UAS, some of 151 which need or want to inspect LI (which would seem to qualify them as 152 LRs) and some of them will not. While SIP proxy servers generally 153 are not RFC4119-aware and do not need to inspect SIP request bodies 154 in order to perform their function, nothing precludes proxy servers 155 inspecting or logging any SIP message bodies, including LI. 156 Furthermore, it is very difficult for the UAC to anticipate which 157 intermediaries and which eventual UAS a SIP request might reach. 159 This architecture is further complicated by the possibility of 160 sending location information by-reference, that is, placing a URL 161 where LI can be retrieved in SIP requests instead of using a PIDF-LO 162 body (commonly called including the PIDF-LO by value) Depending on 163 the qualities of a reference, further authorization checks may be 164 performed before LI is retrieved, LI may be customized depending on 165 who is asking, and so forth. As will be discussed in greater detail 166 below, the conveyance of a reference may have very different privacy 167 properties than conveying a PIDF-LO body by-value in a SIP request. 169 In this architecture, the question of who is an "authorized 170 recipient" from the point of view of the Rule Maker has been muddy. 172 The SIP elements along the path are authorized to receive and forward 173 the SIP message; does that make them automatically authorized 174 recipients of the LI it contains? The final target of the SIP 175 message will receive the LI along with other information, but it may 176 be different than the initial target in a variety of scenarios; is it 177 authorized to read the LI? 179 These questions and concerns are particularly problematic when 180 is set to "no" (the default case). This 181 core concern might be put as "to whom does 182 apply in location-based routing?" More specifically: 184 Is any entity that reads LI bound by ? If 185 so, does that mean a proxy that performs location-based routing is 186 unable to forward a request and complete a SIP call if 187 is "no"? Alternatively, must they strip the 188 location body from the message in order to complete the call? 190 If the proxy does not understand RFC4119, it may forward a SIP 191 message containing a policy statement set to 192 "no". Is any proxy that does understand RFC4119 required to parse 193 the LI for this statement, even if it would not do so in order to 194 route the message? 196 Is there a need for SIP-level indications regarding retransmission 197 for the benefit of entities that do not understand 4119? 199 Since the UAC cannot anticipate who may receive a SIP request, how do 200 we understand who the intended LR is in the location-based routing 201 case? Can a UAC have intended for there to be multiple serial LRs in 202 a transmission? If so, if one LR is authorized to retransmit to 203 another LR, how will it know it is not also authorized to transmit LI 204 to other third parties (i.e., how will the serial LRs know to whom 205 they are authorized to retransmit)? How could all of this be 206 designated? 208 3. Recommendation 210 The following sections provide a recommendation for how the 211 flag should be understood in a SIP 212 environment. The core semantics of this recommendation represent the 213 consensus of the GEOPRIV working group. While Section 3.5 proposes a 214 syntax that might be adopted by the SIP WG to implement these 215 semantics in its protocol, the actual syntax of SIP is the 216 responsibility of the SIP WG. 218 3.1. Goals 220 After extensive discussion in both GEOPRIV and SIP contexts, there 221 seems to be consensus that a solution for this problem must enable 222 location-based routing to work even when the 223 flag is set to "no". A solution should also give the Rule Maker the 224 ability to allow or forbid the use of LI for location-based routing 225 and the ability to allow or forbid the use of LI for the consumption 226 of the endpoint. 228 3.2. Core Semantics 230 Consensus has emerged that any SIP entity which receives a SIP 231 message containing LI through the operation of SIP's normal routing 232 procedures or as a result of location-based routing should be 233 considered an authorized recipient of that LI. Because of this 234 presumption, one SIP element may pass the LI to another even if the 235 LO it contains has set to "no"; this sees 236 the passing of the SIP message as part of the delivery to authorized 237 recipients, rather than as retransmission. SIP entities are still 238 enjoined from passing these messages outside the normal routing to 239 external entities if is set to "no", as it 240 is the passing to 3rd parties that is meant 241 to control. 243 This architecture is considerably different from the presumptions of 244 RFC3963, in that authorized recipients pass the LO on to other 245 authorized recipients, but it seems to be the most sensible mechanism 246 given SIP's operation. 248 To maintain the Rule Maker's ability to affect the consumption of 249 this information, two different mechanisms may be used to limit the 250 distribution of LI and one may used to limit the sphere in which it 251 may be used; these are discussed below. 253 3.3. Limiting Access 255 3.3.1. Limiting Access using Public Key Encryption 257 One way of limiting access to LI is to encrypt the PIDF-LO object in 258 a SIP request. If the originator knows which specific entity on the 259 path needs to inspect the LI, and knows a public key for that entity, 260 this is a straightforward matter. It is even possible to encrypt 261 multiple instance of PIDF-LO, containing different policies or levels 262 of location granularity, in the same SIP request if multiple entities 263 along the path need to inspect the location. 265 This is most likely to be effective in cases where the originator 266 does not wish the LI to be inspected by intermediate entities and has 267 the public key for the target of the SIP message, as it is very 268 difficult for the originator to anticipate the intermediaries through 269 which a SIP message will pass. It may also be useful in limited 270 environments where the originator has a trust relationship with a 271 specific SIP element (e.g. a "home" or first-hop proxy) and it wants 272 to reveal that LI only to that element. 274 Note that even in the case where the originator intends to encrypt LI 275 for the benefit only of the target of the message it may be quite 276 difficult to anticipate the eventual endpoint of the message. These 277 encrypted LIs will not be useful in any case where the anticipation 278 of the originators is not met. 280 An additional problem posed by this approach is that it requires some 281 sort of public key discovery system, which compounds the operational 282 complexity significantly. While this method is included for 283 completeness, it is the consensus of the working group that the 284 deployment scenarios in which this is appropriate will be relatively 285 few; we do not believe it is an appropriate baseline approach. 287 3.3.2. Limiting Access using Location-by-Reference 289 Another, more feasible approach is leveraging location by reference. 290 When a SIP request conveys a reference, it cannot be properly said to 291 be conveying location; location is conveyed upon dereferencing the 292 URI in the question, and the meaning of must 293 be understood in the context of that conveyance, not the forwarding 294 of the SIP request. 296 The properties of references, especially the security properties, 297 vary significantly depending on the nature and disposition of the 298 resource indicated. Clearly, if the referenced PIDF-LO is available, 299 in the same form, to any entity along the SIP signaling path that 300 requests it, then inserting a reference has no advantages over 301 inserting LI by value (and introduces wasteful complexity). However, 302 if the Rule Maker influences the results of the dereferencing 303 process, including determining who can receive LI at what degree of 304 granularity and what policies are bound with the LI, the security 305 properties are different. 307 It might superficially appear that this suffers from the same 308 problems as the encryption approach, since the Rule Maker must 309 anticipate a set of entities who are authorized to receive location 310 information. The difference is that this set does not need to be 311 communicated in the SIP request in order for authorization decisions 312 to be made. There is a world of difference between managing a 313 whitelist of a thousand parties that might ask for LI and sending a 314 SIP request containing a thousand differently-encrypted adumbrations 315 on LI - the former is commonplace and the latter is impossible. 316 Additionally, some Rule Maker policies might not even require the 317 establishment of an exhaustive whitelist. For example, it may be 318 that there exists a finite set of commercial requestors that the Rule 319 Maker would like to block, in a manner similar to the way ad-blockers 320 operate in modern web browsers. 322 In any system where one makes an authorization decision, a certain 323 cost in authentication must be paid - the greater the assurance the 324 greater the cost. The precise cost will of course depend on the URI 325 scheme of the reference. For SIP, Digest has a low computational 326 cost but requires pre-established keys, which limits applicability. 327 RFC4474 Identity does not require any pre-association, but it does 328 make signaling more heavyweight and requires the deployment of 329 additional features in the network, including a web-like PKI. 331 But even if no authentication takes place, in the LbyR case the 332 meaning of is unambiguous - each entity to 333 which LI is conveyed in the dereference process is bound by the 334 retransmission policy. The cost of the reference itself is of course 335 the server that maintains the resource. While not every SIP client 336 has access to an appropriate server for this purpose, the fact that 337 PIDF-LO builds on the typical SIP presence service makes this less 338 implausible than it might be. Moreover, the LbyR approach casts the 339 conveyance architecture in a manner familiar from RFC3693, with a 340 Location Server receiving requests from Location Recipients which may 341 be accepted or denied. This allows the preservation of the original 342 semantics of . 344 3.3.3. Refraining from Including Location Information 346 The most fundamental mechanism for limiting access to location 347 information is simply not including it. While location-based-routing 348 might conceivably occur in almost any SIP message in the future, 349 there is no requirement that location be included in the general case 350 to support it. If it is not included and is required, an appropriate 351 error indicating the lack may be returned and the choice made to 352 continue communication with the information included. This challenge 353 and response will slow the establishment of communication when it is 354 required, but it is the most basic way to ensure that location 355 distribution is limited to the times when it is required for 356 communication to proceed. 358 3.4. Choosing Among the Available Mechanisms 360 Refraining from including location is the most appropriate choice for 361 systems that do not wish to reveal location to any party in the SIP 362 path. 364 Location-by-Reference is generally recommended as the most deployable 365 mechanism for limiting access to LI which is passed via a SIP 366 message. It is significantly easier to deploy than public key 367 discovery systems, allows for both whitelists and blacklists, and can 368 scale in ways that the inclusion of multiple encrypted bodies cannot. 369 Encryption may be used in a limited set of circumstance where 370 location-by-value must be used. 372 3.5. Indicating Permission to Use Location-Based Routing in SIP 374 The discussion in Section 3.3.2 describes 3 mechanisms for limiting 375 the distribution of LI to specific entities. There remains the 376 problem of limiting the use to which LI included by value or by 377 reference may be put. In order to meet the need to limit that use, 378 this document recommends the creation of a syntactical element in SIP 379 to carry this information. As an exemplary concrete proposal, we 380 recommend a "Location-Routing-Allowed" header as described below. 382 When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is 383 indicating permission to use the included LI for location-based 384 routing. When "Location-Routing-Allowed" is set to "No", the 385 originator is indicating that this use is not permitted. "Location- 386 Routing-Allowed" being set to "No" has no protocol-level mechanism 387 for enforcement of this behavior; like the PIDF-LO being set to "no", it is a way for the Rule Maker to express 389 a preference to the SIP elements which are LI recipients. It may, 390 however, present a significant optimization. Where a location-by- 391 reference is included with "Location-Routing-Allowed" set to "No", 392 the SIP elements along the path know that they do not need to attempt 393 to dereference the location information; this is significantly faster 394 than attempting the dereference and being denied at the 395 authentication stage. 397 We recommend that "Location-Routing-Allowed" be made mandatory-to- 398 implement for elements complying with [1]. 400 We recommend that it appear in any SIP message that contains a 401 location, whether by reference or by value. 403 We recommend that any SIP message containing a location but no 404 "Location-Routing-Allowed" header should be treated as containing a 405 "Location-Routing-Allowed" header set to "No". 407 We recommend that a UA be allowed to insert a "Location-Routing- 408 Allowed" header even when it has not included a location, in order to 409 set the policy for any locations inserted by other SIP elements. 411 This allows the UA to assert that it is a Rule Maker for locations, 412 even when the network architecture in which the UA is present inserts 413 the location into SIP messages after the UA has originated the SIP 414 exchange. 416 We recommend that any SIP element inserting a location, whether by 417 reference or by value, insert a "Location-Routing-Allowed header if 418 one is not already present. If one is present, it should not be 419 over-ridden by the SIP element inserting the location. 421 We recommend that any SIP element not the originator of a message and 422 not inserting a location be enjoined from inserting a "Location- 423 Routing-Allowed" header. 425 3.6. Behavior of Back-to-Back User Agents 427 While the behavior of back-to-back user agents (B2BUAs) is outside 428 the scope of SIP standardization, there are nevertheless ways that a 429 B2BUA might approach conveyed location information and the 430 flag that will have better results than 431 others. This section documents the consequences of B2BUA behavior 432 interacting with . 434 Typically, B2BUAs are described as terminating one session and 435 originating a new one. From that perspective, a B2BUA receiving LI 436 on one of its "backs" might treat itself as terminating the flow of 437 information and thus view itself as a recipient for the purposes of 438 . In that case, it should originate a new 439 information flow containing that LI by value in the other direction 440 only if the PIDF-LO it receives permitted it (i.e. if 441 is set to 'yes'). If the PIDF-LO it 442 receives is encrypted, it can pass it onward with the understanding 443 that a recipient capable of decrypting it is authorized; the B2BUA 444 does not seem to be a recipient in this instance. 446 Note that this case is also easier to handle using the location-by- 447 reference model. Since the passing of location-by-reference does not 448 properly include the location itself, it can pass a location-by- 449 reference pointer in the new direction with the understanding that 450 the dereferencing protocol handles the determination of whether those 451 dereferencing the location are authorized recipients or not. 453 If both sides of a B2BUA speak SIP, note that failing to copy any 454 "Location-Routing-Allowed" header value found in the input flow when 455 it re-originates the flow will neglect the policies of the Rule 456 Maker. 458 4. IANA Considerations 460 This memo includes no request to IANA. 462 5. Security Considerations 464 The privacy and security implications of distributing location 465 information are the fundamental subject of this document. 467 6. Acknowledgements 469 James Polk provided a series of questions regarding the specifics of 470 the Location-Routing-Allowed mechanism, and this resulted in the 471 recommendations in Section 3.4. 473 7. Informative References 475 [I-D.ietf-sip-location-conveyance] 476 Polk, J. and B. Rosen, "Location Conveyance for the 477 Session Initiation Protocol", 478 draft-ietf-sip-location-conveyance-10 (work in progress), 479 September 2008. 481 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 482 A., Peterson, J., Sparks, R., Handley, M., and E. 483 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 484 June 2002. 486 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 487 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 489 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 490 Format", RFC 4119, December 2005. 492 Authors' Addresses 494 Jon Peterson 495 NeuStar, Inc. 497 Email: jon.peterson@neustar.biz 498 Ted Hardie 499 Qualcomm 501 Email: hardie@qualcomm.com 503 John Morris 504 CDT 506 Email: jmorris@cdt.org 508 Full Copyright Statement 510 Copyright (C) The IETF Trust (2008). 512 This document is subject to the rights, licenses and restrictions 513 contained in BCP 78, and except as set forth therein, the authors 514 retain all their rights. 516 This document and the information contained herein are provided on an 517 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 518 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 519 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 520 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 521 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org.