idnits 2.17.1 draft-ietf-iptel-trunk-group-02.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 528), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To the processing UAS, a trunk group in the R-URI implies that it should use the named trunk group for the outbound call. If a UAS supports trunk groups but is not configured with the particular trunk group identified in the R-URI, it SHOULD not use any other trunk group other than the one requested. -- 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 23, 2004) is 7124 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2806 (ref. '4') (Obsoleted by RFC 3966) == Outdated reference: A later version (-09) exists of draft-ietf-iptel-rfc2806bis-02 == Outdated reference: A later version (-09) exists of draft-ietf-iptel-tgrep-02 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL WG V. Gurbani 3 Internet-Draft Lucent Technologies 4 Expires: April 23, 2005 C. Jennings 5 Cisco Systems 6 J. Peterson 7 NeuStar 8 October 23, 2004 10 Representing trunk groups in tel/sip URIs 11 draft-ietf-iptel-trunk-group-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 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 23 Internet-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 23, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document describes a standardized mechanism to convey trunk 45 group- related information in SIP and TEL URIs. An extension to the 46 "tel" URI is defined for this purpose. 48 This work is being discussed on the iptel@ietf.org mailing list. 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Problem statement . . . . . . . . . . . . . . . . . . . . . 3 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Requirements and rationale . . . . . . . . . . . . . . . . . 4 56 4.1 sip URI or tel URI? . . . . . . . . . . . . . . . . . . . 4 57 4.2 Trunk group namespace: global or local? . . . . . . . . . 5 58 4.3 Originating trunk group and terminating trunk group . . . 5 59 4.4 Intermediary processing of trunk groups . . . . . . . . . 5 60 5. Reference architecture . . . . . . . . . . . . . . . . . . . 6 61 6. Trunk group identifier: ABNF and examples . . . . . . . . . 7 62 7. Example call flows . . . . . . . . . . . . . . . . . . . . . 8 63 7.1 Trunk group in a Contact header . . . . . . . . . . . . . 8 64 7.2 Trunk group in the R-URI . . . . . . . . . . . . . . . . . 9 65 8. Security considerations . . . . . . . . . . . . . . . . . . 9 66 9. IANA considerations . . . . . . . . . . . . . . . . . . . . 10 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 68 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 11.1 Changes from draft-ietf-trunk-group-01 . . . . . . . . . 10 70 11.2 Changes from trunk-group-00 . . . . . . . . . . . . . . 10 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 12.1 Normative References . . . . . . . . . . . . . . . . . . . 10 73 12.2 Informative References . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 75 Intellectual Property and Copyright Statements . . . . . . . 13 77 1. Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC-2119 [1]. 83 2. Problem statement 85 Currently, there isn't any standardized manner of transporting 86 trunk-groups between Internet signaling entities. This leads to 87 ambiguity on at least two fronts: 89 1. Positional ambiguity: A SIP proxy that wants to send a call to an 90 egress VoIP gateway may insert the trunk-group as a parameter in 91 the user portion of the Request-URI (R-URI), or it may insert it 92 as a parameter to the R-URI itself. This ambiguity persists in 93 the reverse direction as well, that is, when an ingress VoIP 94 gateway wants to send a incoming call notification to its default 95 outbound proxy. 96 2. Semantic ambiguity: The lack of any standardized grammar to 97 represent trunk groups leads to the unfortunate choice of ad hoc 98 names and values. 100 VoIP routing entities in the Internet, such as SIP proxies, may be 101 interested in using trunk-group information for normal operations. 102 To that extent, any standards-driven requirements will enable proxies 103 from one vendor to interoperate with gateways from yet another 104 vendor. Absence such guidelines, inter-operability will suffer as a 105 proxy vendor must conform to the expectations of a gateway as to 106 where it expects trunk-group information to be present (and vice 107 versa). 109 The aim of this Internet draft is to outline how to structure and 110 represent the trunk group information as an extension to the tel URI 111 [5] in a standardized manner. 113 3. Definitions 115 Before we take the discussion of trunks any further, we must define 116 both a trunk and a trunk group and explain the difference between the 117 two. The following definitions are taken from [6]. 119 Trunk: In a network, a communication path connecting two switching 120 systems used in the establishment of an end-to-end connection. In 121 selected applications, it may have both its terminations in the 122 same switching system. 123 Trunk Group: A set of trunks, traffic engineered as a unit, for 124 the establishment of connections within or between switching 125 systems in which all of the paths are interchangeable except where 126 subgrouped. 128 Since the introduction of ubiquitous digital trunking, which resulted 129 in the allocation of DS0s between end offices in minimum groups of 24 130 (in North America), it has become common to refer to bundles of DS0s 131 as a trunk. Strictly speaking, however, a trunk is a single DS0 132 between two Public Switched Telephone Network (PSTN) end offices - 133 however, for the purposes of this document, the PSTN interface of a 134 gateway acts effectively as an end office (i.e. if the gateway 135 interfaces with SS7, it has its own SS7 point code, and so on). A 136 trunk group, then, is a bundle of DS0s (that need not be numerically 137 contiguous in an SS7 Trunk Circuit Identification Code (TCIC) 138 numbering scheme) which are grouped under a common administrative 139 policy for routing. 141 A SIP-PSTN gateway may have trunks that are connected to different 142 carriers. It is entirely reasonable for a SIP proxy to choose -- 143 based on factors not enumerated in this document -- which carrier a 144 call is sent to when it proxies a session setup request to the 145 gateway. Since multiple carriers can terminate a particular PSTN 146 phone number, the phone number itself is not sufficient enough to 147 identify the carrier at the gateway. An additional piece of 148 information in the form of a trunk group can be used to further pare 149 down the choices at the gateway. How the proxy picked a particular 150 trunk group is outside the scope of this document (reference [7] 151 provides one such way); once the trunk group has been decided upon, 152 this document provides a standardized means to represent it. 154 4. Requirements and rationale 156 4.1 sip URI or tel URI? 158 REQ 1: Trunk group information MUST be carried in the "tel" URI [5]. 160 The trunk group information can be carried in either the "sip" URI 161 [3] or the "tel" URI [4,5]. Since trunks groups are intimately 162 associated with the PSTN (Public Switched Telephone Network), it 163 seems reasonable to define them as extensions to the "tel" URI (any 164 SIP request that goes to a gateway could reasonably be expected to 165 have a tel URL, in whole or in part, in its R-U anyway). 166 Furthermore, using the tel URL also allows this format to be re-used 167 by non-SIP VoIP protocols (which could include anything from MGCP or 168 Megaco to H.323, if the proper IEs are created). 170 Finally, once the trunk-group is defined for a "tel" URI, the 171 normative procedures of Section 19.1.6 in [3] can be used to derive 172 an equivalent "sip" URI from a "tel" URI, complete with the trunk 173 group information. 175 4.2 Trunk group namespace: global or local? 177 REQ 2: To prevent inadvertent inter-domain trunk group naming 178 collisions, a name space MUST be defined which must be flexible 179 enough to both accommodate local naming conventions and provide 180 global naming semantics. 182 Under normal operations, trunk groups have meaning only within an 183 administrative domain (i.e. local scope). However, to prevent 184 inadvertent cross-domain trunk group collisions (which, given 185 Murphy's law, will happen), a global scope appears to be useful. The 186 "phone-context" parameter of the tel URI is used to impose a 187 namespace by specifying a domain where the trunk groups are 188 understood. 190 The use of the "phone-context" parameter in conjunction with this 191 draft is mandatory; implementations choosing to include trunk groups 192 in SIP signaling MUST be capable of parsing and generating the 193 "phone-context" parameter of the tel URI. If a receiver of a SIP 194 request is not the owner of the domain specified in the 195 "phone-context", it MUST treat the trunk group as if it was not 196 there. 198 4.3 Originating trunk group and terminating trunk group 200 REQ 3: Originating trunk group and destination trunk group SHOULD be 201 able to appear separately and concurrently in a SIP message. 203 SIP routing entities can make informed routing decisions based on 204 either the originating or the terminating trunk groups. Thus a 205 requirement that both of these trunk groups need to be carried in SIP 206 requests. Instead of having two parameters, one for the originating 207 trunk group and the other for a terminating trunk group, the 208 placement of the trunk group parameter in a SIP Contact header or the 209 R-URI, respectively, signifies the intent. 211 4.4 Intermediary processing of trunk groups 213 REQ 4: SIP network intermediaries (proxy server and redirect servers) 214 should be able to add the destination trunk group attribute to SIP 215 sessions as a route is selected for a call. 217 If the trunk group parameter appears in a R-URI of a request, it 218 represents the destination trunk group. 220 This is consistent with using the R-URI as a routing element; SIP 221 routing entities may use the trunk group parameter in the R-URI to 222 make intelligent routing decisions. Furthermore, this also 223 satisfies REQ 4, since a SIP network intermediary can modify the 224 R-URI to include the trunk group information. 226 To the processing UAS, a trunk group in the R-URI implies that it 227 should use the named trunk group for the outbound call. If a UAS 228 supports trunk groups but is not configured with the particular trunk 229 group identified in the R-URI, it SHOULD not use any other trunk 230 group other than the one requested. 232 A UAC that initiates a call and supports this draft MAY include the 233 trunk group in the Contact header. If it does so, the trunk group in 234 the Contact header represents the originating trunk group. 235 Subsequent requests destined to that UAC MUST copy the trunk group 236 from the Contact header into the R-URI. Note that a Contact URI MUST 237 be a sip URI, thus, what appears in the Contact header is a 238 SIP-translation of the tel URI, complete with the trunk group 239 information. 241 Arguably, the originating trunk group can be part of the From URI. 242 However, semantically, the URI in a From header is an abstract 243 identifier which represents the resource thus identified on a 244 long-term basis. The presence of a trunk group, on the other 245 hand, signifies a binding that is valid for the duration of the 246 session only; a trunk group has no significance once the session 247 is over. Thus, the Contact URI is the best place to impart this 248 information since it has exactly those semantics. 250 5. Reference architecture 252 Consider Figure 1, which depicts a SIP proxy in a routing 253 relationship with three gateways in its domain, GW1, GW2, and GW3. 254 Among other sources of request arrival (not shown in Figure) at the 255 proxy is GW1. Gateways GW2 and GW3 are used as egress gateways from 256 the domain. GW2 has two trunk groups configured, TG2-1 and TG2-2. 257 GW3 has only one trunk group configured TG3-1. 259 +-----+ TG2-1 260 | |--------> To 261 TG1-1 +-----+ +-------+ +---->| GW2 | TG2-2 PSTN 262 From ----->| | | SIP | | | |--------> 263 PSTN | GW1 |--->| Proxy |-----+ +-----+ 264 ----->| | +-------+ | +-----+ TG3-1 265 +-----+ | | |--------> To 266 +---->| GW3 | PSTN 267 | |--------> 268 +-----+ 269 Figure 1: Reference architecture 271 On requests arriving to the proxy from GW1, the proxy will have 272 access to the trunk group TG1-1 if the request arrived on that 273 particular trunk. If the receiving gateway (GW1, in this case) wants 274 to propagate the ingress trunk group to the proxy, it MUST arrange 275 for the trunk group to appear in the Contact header of the SIP 276 request destined to the proxy. 278 The proxy uses GW2 and GW3 as egress gateways to the PSTN. It is 279 assumed that the proxy has access to a routing table for GW2 and GW3 280 which includes the appropriate trunk groups to use when sending a 281 call to the PSTN (exactly how this table is constructed is out of 282 scope for this draft; [7] is one way to do so, a manually created and 283 maintained routing table is another). When the proxy sends a request 284 to either of the egress gateways, and the gateway routing table is so 285 configured that a trunk group is required by the gateway, the proxy 286 MUST arrange for the trunk group to appear in the SIP R-URI of the 287 request destined to that gateway. 289 6. Trunk group identifier: ABNF and examples 291 The ABNF syntax [2] for a trunk group identifier is given below and 292 extends the "par" production rule of the tel URI defined in [5]: 294 par = parameter / extension / isdn-subaddress / trunk-group 296 trunk-group = ";tgrp=" trunk-group-label 297 trunk-group-label = *1( unreserved / escaped / 298 trunk-group-unreserved ) 299 trunk-group-unreserved = "/" / "&" / "+" / "$" 301 trunk-group-unreserved is the intersection of param-unreserved 302 defined in [5] and user-unreserved defined in [3]. Since the 303 trunk group is an extension to the tel URI and will end up as the 304 user portion of a SIP URI, the ABNF for it has to ensure that it 305 can be adequately representated in both the constructs. 307 Examples: 309 tel:+15555551212;tgrp=tg55;phone-context=telco.example.com 310 tel:0216;tgrp=TG-1;phone-context=+1-555-555 312 The example URIs above extends the tel URI with a trunk group 313 identifier. Transforming these "tel" URI to "sip" URIs yields, 314 respectively: 316 sip:+15555551212;tgrp=tg55;phone-context=telco.example.com@isp.example.net 317 sip:0216;tgrp=TG-1;phone-context=+1-555-555@isp.example.net 319 7. Example call flows 321 7.1 Trunk group in a Contact header 323 This call flow depicts a gateway accepting a call from the PSTN and 324 conversing with its SIP proxy in order to further route the call 325 (F1). At some later time after the call has been established, the 326 gateway receives a BYE (F2) to tear down the call (note the R-URI in 327 the BYE). 329 PSTN Ingress Proxy 330 Gateway 331 | | | 332 |Call Request | | 333 +------------->| | 334 | +---F1----->| 335 ... ... ... 336 | | 337 | |<----F2--- 339 F1: 340 INVITE sip:40216@isp.example.net SIP/2.0 341 ... 342 Contact: 343 ... 345 F2: 346 BYE sip:40216;tgrp=tg55;phone-context=isp.example.net@igwy.isp.example.net 347 ... 349 7.2 Trunk group in the R-URI 351 This call flow depicts a proxy sending a request to a gateway with a 352 particular trunk group (F1). The gateway sends the request to the 353 PSTN; when the callee picks up the phone, a 200 OK is generated 354 towards the UAC (F2). Note the Contact of the 200 OK; it contains 355 the trunk group information. Subsequent requests from the UAC will 356 contain this URI as the R-URI. 358 UAC Proxy Egress 359 Gateway 360 | | | 361 |Call Request | | 362 +------------->| | 363 | +---F1------>| 364 | | |---> Interface with PSTN and 365 | | | received Answer Complete Message (ACM) 366 | +<-------F2--+ 367 | | | 368 ... ... ... 370 F1: 371 INVITE sip:+15555551212;tgrp=TG2-1;phone-context=isp.example.net@egwy.isp.example.net SIP/2.0 372 ... 373 F2: 374 SIP/2.0 200 OK 375 ... 376 Contact: 378 8. Security considerations 380 The extension defined in this document does not add any additional 381 security concerns beyond those already enumerated in [3] . The trunk 382 group information is carried in Request-URIs and Contact headers; it 383 is simply a modifier of an address, and the trust imparted to that 384 address is not affected by such a modifier. The privacy information 385 revealed with trunk groups does not generally reveal much information 386 about a particular (human) user. It does, however, reveal two pieces 387 of potentially private information which may be considered sensitive 388 by carriers. First, it may reveal how a carrier may be performing 389 least-cost routing and peering; and secondly, it does introduce an 390 additional means for network topology and information of a carrier. 391 If revealing this information is considered a privacy concern by a 392 carrier, it should take precautions to hide it. 394 9. IANA considerations 396 Section 9 of [5] creates a registry for tel URI parameters. This 397 document updates the registry with the following entry: 398 Parameter name: tgrp 399 Description: A trunk group on which an incoming call was received 400 at an ingress gateway or a trunk group on which an outgoing call 401 should be placed at an egress gateway. 402 This parameter is not mandatory. 403 Syntax restrictions: Details on the syntax are explained in RFC 404 AAAA. A phone-context parameter must occur in any tel URL that 405 contains a tgrp parameter. 406 Reference: RFC AAAA 407 [Note to RFC editor: Please replace AAAA with the RFC number 408 assigned to this document.] 410 10. Acknowledgments 412 The authors would like to acknowledge the efforts of all the 413 participants in the SIPPING and IPTEL working group. Special thanks 414 to John Hearty, Alan Johnston, Rohan Mahy, Mike Pierce, Adam Roach, 415 Jonathan Rosenberg, Bryan Byerly, Dave Oran, Tom Taylor, and Al 416 Varney for insightful discussions and comments. 418 11. Changes 420 11.1 Changes from draft-ietf-trunk-group-01 421 1. Changed file name. 423 11.2 Changes from trunk-group-00 424 1. Changed tgrp=local syntax. 425 2. Introduction of "phone-context" parameter. 426 3. Redid the Examples section and added an architecture diagram. 428 12. References 430 12.1 Normative References 432 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 433 Levels", BCP 14, RFC 2119, March 1997. 435 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 436 Specifications: ABNF", RFC 2234, November 1997. 438 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 439 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 441 Session Initiation Protocol", RFC 3261, June 2002. 443 [4] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 444 2000. 446 [5] Schulzrinne, H. and A. Vaha-Sipila, "The tel URI for Telephone 447 Calls", draft-ietf-iptel-rfc2806bis-02 (work in progress), July 448 2003. 450 12.2 Informative References 452 [6] "Bellcore Notes on the Network", Telcordia SR2275, Dec 1997, 453 . 455 [7] Bangalore, M., Kumar, R., Rosenberg, J., Salama, H. and D. Shah, 456 "A Telephony Gateway REgistration Protocol (TGREP)", 457 draft-ietf-iptel-tgrep-02.txt (work in progress), December 2003. 459 Authors' Addresses 461 Vijay Gurbani 462 Lucent Technologies 463 2000 Lucent Lane 464 Rm 6G-440 465 Naperville, IL 60566 466 USA 468 Phone: +1 630 224 0216 469 EMail: vkg@lucent.com 471 Cullen Jennings 472 Cisco Systems 473 170 West Tasman Drive 474 Mailstop SJC-21/3 475 San Jose, CA 95134 476 USA 478 Phone: +1 408 421 9990 479 EMail: fluffy@cisco.com 480 Jon Peterson 481 NeuStar 482 1800 Sutter St. 483 Suite 570 484 Concord, CA 94520 485 USA 487 Phone: +1 925 363 8720 488 EMail: jon.peterson@neustar.biz 490 Intellectual Property Statement 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed to 494 pertain to the implementation or use of the technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; nor does it represent that it has 497 made any independent effort to identify any such rights. Information 498 on the procedures with respect to rights in RFC documents can be 499 found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use of 504 such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository at 506 http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at 512 ietf-ipr@ietf.org. 514 Disclaimer of Validity 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 AND THE INTERNET 519 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 520 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 521 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 522 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 524 Copyright Statement 526 Copyright (C) The Internet Society (2004). This document is subject 527 to the rights, licenses and restrictions contained in BCP 78, and 528 except as set forth therein, the authors retain all their rights. 530 Acknowledgment 532 Funding for the RFC Editor function is currently provided by the 533 Internet Society.