diff options
Diffstat (limited to 'doc/rfc/rfc5346.txt')
| -rw-r--r-- | doc/rfc/rfc5346.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5346.txt b/doc/rfc/rfc5346.txt new file mode 100644 index 0000000..308783d --- /dev/null +++ b/doc/rfc/rfc5346.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group J. Lim +Request for Comments: 5346 W. Kim +Category: Informational C. Park + NIDA + L. Conroy + RMRL + October 2008 + + + Operational Requirements for ENUM-Based Softswitch Use + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This document describes experiences of operational requirements and + several considerations for ENUM-based softswitches concerning call + routing between two Korean Voice over IP (VoIP) carriers, gained + during the ENUM pre-commercial trial hosted by the National Internet + Development Agency of Korea (NIDA) in 2006. + + These experiences show that an interim solution can maintain the + stability of ongoing commercial softswitch system operations during + the initial stage of ENUM service, where the DNS does not have + sufficient data for the majority of calls. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Call Routing on Softswitch . . . . . . . . . . . . . . . . . . 2 + 3. Infrastructure ENUM Trial in Korea . . . . . . . . . . . . . . 3 + 4. Operational Requirements for ENUM-Based Softswitches . . . . . 4 + 4.1. Call Routing Cases for DNS Response Codes . . . . . . . . 4 + 4.1.1. Trial Policies . . . . . . . . . . . . . . . . . . . . 4 + 4.1.2. Trial ENUM Lookup Rules . . . . . . . . . . . . . . . 6 + 4.2. Call Routing Cases for Domainparts . . . . . . . . . . . . 7 + 5. Trial Results . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. 'e164.arpa' Considerations . . . . . . . . . . . . . . . . . . 9 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 + + + + +Lim, et al. Informational [Page 1] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + +1. Introduction + + ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035] + that converts from an E.164 [E164] number to a domain name using the + Naming Authority Pointer (NAPTR) [RFC3403] resource record type. + ENUM is able to store different service types (such as fax, email, + homepage, SIP, H.323 and so on) for every E.164 number. It + originally focused on how end-users could gain access to other end- + users' communication contact information through the Internet. + + Recently, discussion on the need to update RFC 3761 has begun to + ensure that the standard also works in the "Infrastructure ENUM" + scenario, where ENUM provides routing information between carriers. + This resulted in two documents, the updated ENUM specification + [RFC3761bis] and an Enumservice guide [ENUMSERVICE-GUIDE]. + + When providing VoIP service, a VoIP carrier that wants to integrate + various protocols typically uses a softswitch. However, such a + system is still inefficient for interconnection, number portability, + and sharing protocol support information among carriers, because each + softswitch does not have complete end-to-end routing information for + all carriers. This information can be stored in DNS, using ENUM. + Therefore, carriers can expect to gain many advantages if they use + ENUM within the call routing functions of their softswitches. + + To confirm these benefits and to verify the performance of ENUM- + enabled softswitches, NIDA cooperated with two Korean VoIP service + providers for an Infrastructure ENUM trial in 2006. NIDA is a non- + profit organization with a mandate to manage 2.8.e164.arpa. + (representing the +82 country code of Korea). NIDA promotes and + facilitates technical cooperation on a national scale between + partners, and this includes ENUM. During the trial, NIDA provided a + centralized ENUM DNS to each VoIP service provider for call routing. + The data used in this Infrastructure trial was also accessible to the + public (i.e., it was an Internet-based system, rather than a closed + scheme). + +2. Call Routing on Softswitch + + In the PSTN (Public Switched Telephone Network), hardware-based + switches predominate. A softswitch provides similar functionality, + but is implemented on a computer system by software. It typically + has to support various signalling protocols (such as SIP [RFC3261], + H.323 [H323], Media Gateway Control Protocol (MGCP) [RFC3435], and + others) to make call connections for VoIP service, often on the + boundary point between the circuit and packet network. + + + + + +Lim, et al. Informational [Page 2] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + To make a call, first of all a softswitch must discover routing + information. It has to process the E.164 number that comes from a + caller through its own routing table. The goal is to determine how + the call can be routed towards the callee, so that either the call + can be processed through the softswitch or the caller can connect to + the callee directly. + + Today, call routing is often based on a prefix of the dialled number. + This is used very widely not only for legacy PSTN switches, but also + for softswitches. So, if a softswitch exclusively uses ENUM DNS for + call routing, then, in the beginning most of the calls queried to + ENUM DNS would fail if there are only a small group of carriers + provisioning data into ENUM. However, a softswitch will have a + higher success rate with ENUM DNS as the number of carriers grows, + and so the overall percentage of numbers provisioned in ENUM + increases. In short, ENUM as a long-term solution has obvious + benefits, but the problem lies in migrating from today's prefix-based + routing towards that long-term ENUM-based solution. + +3. Infrastructure ENUM Trial in Korea + + As described in Section 1, NIDA and two VoIP service providers built + ENUM-processing modules into their softswitches, interconnected these + via the IP network, and provisioned their trial users' numbers into a + centralized ENUM DNS system operated by NIDA. The carriers + provisioned their E.164 numbers using Extensible Provisioning + Protocol (EPP) [RFC4114] to a centralized Registration Server (also + operated by NIDA). Changes to the ENUM data were implemented and + updated to the ENUM DNS instantly, using DNS Dynamic Update + [RFC2136]. + + In the trial, the EPP-based provisioning sub-system was developed and + operated separately from the carriers' main customer provisioning + systems and protocols. It was not integrated, as the carriers + already operated their own customer provisioning systems that were + totally different from the EPP-based model, and (as mission-critical + components) those were not open to modification. + + + + + + + + + + + + + + +Lim, et al. Informational [Page 3] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + Call routing + +---------------------------------------------+ + | | + | | + +-----+------+ +-----------------+ +------+-----+ + |Softswitch A|------| ENUM DNS(+82) |------|Softswitch B| + +-----+------+ | (Tier1,2) | +------+-----+ + | +--------+--------+ | + +-----+------+ | +------+-----+ + | IP Phone A | |Dynamic Update | IP Phone B | + +------------+ |(RFC 2136) +------------+ + | + +------------+ +--------+--------+ +------------+ + | EPP Client | | Registration | | EPP Client | + | |------| Server |------| | + +------------+ +-----------------+ +------------+ + Provisioning E.164 Numbers(RFC 4114) + + Carrier A NIDA Carrier B + + Figure 1: Infrastructure ENUM Trial System Topology + +4. Operational Requirements for ENUM-Based Softswitches + +4.1. Call Routing Cases for DNS Response Codes + + To use ENUM DNS, each softswitch needs to have an ENUM module that + converts from an E.164 number to the ENUM domain name (as defined in + RFC 3761) and processes a query to ENUM DNS. This ENUM module uses + the algorithm specified in RFC 3761. + + However, in the initial stage of ENUM DNS roll-out, ENUM shares call + routing information from a limited number of carriers. There is the + problem that a softswitch can't find all of the call routing + information it needs just using ENUM. To solve this problem, ENUM- + based softswitches have to follow a consistent set of rules. + +4.1.1. Trial Policies + + As a matter of policy in this trial, all telephone numbers in use + within an "ENUM only" number range (i.e., ones in which an endpoint + could only be reached via a URI found during an ENUM lookup of a + telephone number in this range, and for which there was no PSTN Point + of Interconnect) were arranged to return a NAPTR response. For + ranges in which there was a PSTN Point of Interconnect, this was not + required. + + + + + +Lim, et al. Informational [Page 4] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + Thus, no data (at all) needed to be provisioned into an associated + ENUM domain for such a number if it were possible to "reach" that + number via the PSTN, unless there were also an IP-based Point of + Interconnect serving that number and the serving carrier chose to + make this option available. + + In those domains in which NAPTRs for ENUM processing were + provisioned, these NAPTRs were always 'terminal' rules -- non- + terminal NAPTRs were not used. If non-terminal NAPTRs were to be + provisioned, then the standard operation of ENUM processing might + have required extra DNS lookups before the set of NAPTRs for a + telephone number could be evaluated. The delay and indeterminacy + this would introduce was not considered acceptable. + + The case where a valid URI was present is covered in Section 4.1.2 + (rule 2 A, second point). The case where an ENUM entry was not + provisioned for a number that had an active PSTN Point of + Interconnect is covered in Section 4.1.2 (rule 2 B). + + For "ENUM only" ranges, where a given number in that range was in + service (i.e., there was an IP-based Point of Interconnect to a + carrier), a valid SIP or H.323 URI was always provisioned into the + associated ENUM domain. This is covered in Section 4.1.2 (rule 2 A, + second point). + + In such an "ENUM only" range, if the number was not in service, a TXT + record was provisioned but no valid NAPTRs would be present. This + ensured that a query for NAPTRs in a given (out of service, "ENUM + only" range) domain would succeed (i.e., return a RCODE of 0), but + that the number of answers would also be zero. This is covered in + Section 4.1.2 (rule 2 A, first point). Note that this point also + covers the case where only NAPTRs that cannot be used to initiate a + call exist in such a zone. + + Where a valid URI was provisioned, the ENUM lookup would complete by + returning that value for further processing. This further processing + is covered in Section 4.2. + + For "ENUM only" ranges, there was a further policy requirement that + an IP-based Point of Interconnect specified inside a NAPTR (as the + domainpart of a valid URI) must be accessible for all potential + carriers. The server could reject a subsequent SIP Invitation, but + its machine address had to resolve. This was intended to avoid the + condition where the domain name did not resolve, the softswitch logic + would attempt to place the call via the PSTN, and this would fail + and/or loop. + + + + + +Lim, et al. Informational [Page 5] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + This "must resolve" requirement was not needed for numbers that had + an active PSTN Point of Interconnect (i.e., the vast majority of + assigned numbers). If the domain name did not resolve, the call + would "drop back" to PSTN processing. + +4.1.2. Trial ENUM Lookup Rules + + In the Korean trial, the rules were: + + 1. The ENUM module of the softswitch converts an E.164 number coming + from the VoIP subscriber to an ENUM domain name (as defined in + RFC 3761). + + 2. The ENUM module, acting as a DNS stub resolver, sends a query to + a recursive name server. + + 3. If the ENUM module receives a DNS answer, the call routing + process may branch off in several ways, depending on the Rcode + value in the DNS response message, as shown below. + + A. Rcode=0 (No error condition) + There is, potentially, an answer to the corresponding query. + The normal call routing process needs to differentiate + between the following conditions: + + + The response includes no URI (such as SIP or H.323) that + can be used to initiate a call -- + The call fails immediately. + Note: In the trial, the condition in which a telephone + number: + + - is valid, + + - can only be reached via the Internet, but + + - is not currently in service + + is indicated by an ENUM domain that DOES exist but DOES + NOT include any supported (routable) NAPTRs. A softswitch + receiving this response interprets it as indicating that + the call can be dropped immediately -- it would fail if + passed to the PSTN. + + + There is at least one usable URI (such as SIP and/or H.323 + URIs) -- + The softswitch picks one based on the preference and order + field values in the NAPTR Resource Record Set, and routes + the call using the method described in Section 4.2. + + + +Lim, et al. Informational [Page 6] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + B. Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4 + (Not Implemented), or 5 (Refused) + There is no valid answer for the query. + The softswitch has no choice but to route the call using the + E.164 number with its vendor-specific method (such as a + prefix-based method). In this case, it means that the call + has to be delivered through the PSTN for onward call routing. + + It is also important to stress that the ENUM DNS servers must + respond to all queries they receive from the softswitches. + If the ENUM module in a softswitch does not receive a + response, it will eventually time out, and the ENUM module + will treat this as a DNS error. However, the delay involved + is long in terms of the normal call setup time, and should be + avoided. + It would have been possible to modify the DNS code in each + softswitch to have shorter time-outs than normal to cover + misconfiguration of a DNS server, but this choice was not + considered in the trial. The softswitch DNS stack was used + for several purposes other than "pure" ENUM lookups. + Configuring it in a non-complaint manner was considered + unacceptable, due to the need to analyze the impact of that + choice on other DNS operations thoroughly before it could be + implemented safely. + +4.2. Call Routing Cases for Domainparts + + If the DNS response has a valid URI, such as SIP or H.323, the + softswitch can resolve the domain name part of that URI to route a + call by searching two different sources. One is a recursive + nameserver, and the other is a fixed routing table held in the + softswitch, mapping from the domain name to the corresponding + gateway's host name and IP address. + + If there are many points of interconnection, using a recursive + nameserver is useful for resolving a domain name, but if there are + just a few known carriers and they do not change this interconnection + information frequently, a fixed (internal) routing table mapping from + domain name to the corresponding gateway hostname and IP address is + more efficient (rather than querying the recursive nameserver every + time). In addition, carriers would like to charge an interconnection + fee for all received calls, so they tend to make interconnection only + with trusted carriers based on some sort of bilateral agreement + between these carriers. They may agree on a specific gateway for + this purpose, so the interconnection information is often private to + the parties of this particular agreement. + + + + + +Lim, et al. Informational [Page 7] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + In principle, these two approaches could be used in parallel, but in + practice, if the DNS-based approach could be used, there would be no + point in retaining the expensive and elaborate "offline" + infrastructure to exchange and install the tables for domain routing. + In this trial, uncertainty over the performance and reliability of + ENUM-based processing meant that the softswtitches were configured so + that they could be switched between the two approaches immediately. + This was a temporary expedient only, and would not be a reasonable + approach in the long term. + + These two types of domain routing are also affected by the Rcode=0 + case described in Section 4.1. + + There are two choices for routing. These are described and compared + here: + + 1. Case when using a fixed routing table: + + A. If the domain name part of the URI is found in the internal + fixed routing table, the softswitch can use it. + + B. If the domain name part of the URI does not exist in the + fixed routing table, the call is forwarded to the PSTN. + + 2. Case when using a recursive nameserver: + + A. If the domain name part of the URI can be resolved via the + recursive nameserver, the softswitch can use it. + + B. If the domain name part of the URI cannot be resolved on the + recursive nameserver for any reason (such as a response with + no usable resource records according to [RFC3263] and + [RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be + forwarded to the PSTN. + + Case (1) seems inefficient because the administrator maintains two + management points for numbers: the ENUM DNS and the softswitch + itself. However, this configuration can minimize the call routing + failure ratio during the transition period of ENUM (when there are + relatively few provisioned ENUM entries and so few IP-based Points Of + Interconnection). Thus, case (1) could reasonably be implemented on + the softswitches during the trial phase, and thereafter, as ENUM + entries are populated, case (2) would be a reasonable choice. + + With these choices, the two carriers could use ENUM DNS for call + routing without any impact on their ongoing commercial VoIP service. + + + + + +Lim, et al. Informational [Page 8] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + +5. Trial Results + + To provide a stable commercial service, an ENUM-based softswitch must + have a defined performance, in the same way as must any non-ENUM- + based softswitch. The only difference between these two types of + softswitches is the searching mechanism for call routing information, + which can be stored in the softswitch itself or in the DNS. + Therefore, a similar delay time for call routing is important to + guarantee quality of service. During the trial, each carrier + measured this delay time when using the SIP protocol. This was based + on the "Answer Delay time", defined as the elapsed time between + requesting a call ('INVITE' message) and receiving a response ('200 + OK' message) [RFC3261]. + + +------------------------+------+----------+ + | Call Type | ENUM | Non-ENUM | + +------------------------+------+----------+ + | Carrier A->A | 2.33 | 2.28 | + | Carrier A->B | 2.23 | 2.25 | + | Carrier A->other(PSTN) | 4.11 | 3.79 | + | Carrier B->B | 2.18 | 2.05 | + | Carrier B->A | 2.19 | 2.19 | + | Carrier B->other(PSTN) | 3.95 | 3.41 | + +------------------------+------+----------+ + + Table 1: Average Answer Delay Time (Sec) + + As shown in Table 1, there is little difference in time (under a + second) between the ENUM and non-ENUM cases. Therefore, it is + difficult for a caller with either carrier to detect the choice (ENUM + or non-ENUM) as an aspect of quality when a call initiates. This + means that ENUM definitely works well with softswitches on a + commercial basis. + + To make the trial more realistic, the resolver that was used by these + ENUM-based softswitches was a recursive nameserver that could be + accessed publicly. This was done as it was felt that a tough + condition would be better to verify the fact that an ENUM-based + softswitch works as well as a non-ENUM-based softswitch in providing + a commercial VoIP service. + +6. 'e164.arpa' Considerations + + During the trial, the Infrastructure ENUM deployed in the + 2.8.e164.arpa zone could be accessed via the (public) Internet. In + this situation, each carrier questioned whether or not the + centralized number management under the ENUM DNS was realistic. + + + + +Lim, et al. Informational [Page 9] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + Another issue concerned responsibility for routing errors. All + carriers can use the shared ENUM data to route their calls. However, + if there are routing errors (due to the data being provisioned + incorrectly), it is not always clear who has responsibility for these + errors and who can correct the data. The errors occur in the + networks of the carriers placing the calls. Unless the identity of + the carrier responsible for delivering service to this telephone + number is known, it is not obvious (to the carrier handling the + error) who should be informed of these problems. This is a + particular issue when number portability is introduced. + + In addition, the carriers also question whether or not Infrastructure + ENUM needs to be accessible publicly. To prevent disclosure of + telephone numbers, they would prefer to access the ENUM DNS + privately. Therefore, any ENUM module embedded in a softswitch needs + to be flexible to adopt these considerations during the interim + period of ENUM, before common policies and agreements have been + forged. + +7. Security Considerations + + This document inherits the security considerations described in RFC + 3761 and [RFC5067], as the ENUM DNS used with softswitches in this + trial could be accessed publicly. + + In addition, if the recursive resolvers handling ENUM queries coming + from a softswitch were to be compromised by an attacker, that + attacker would be able to force calls to fail or cause delay to + calls. Therefore, the DNS resolvers used should allow access from + the local network to which the softswitch is connected, whilst + restricting access from outside, using a proper access-list policy. + +8. Acknowledgements + + Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim + Reid, and Otmar Lendl who helped guide the direction of this + document, and to Suresh Krishnan, whose GEN-ART review was very + helpful. + + + + + + + + + + + + + +Lim, et al. Informational [Page 10] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + +9. References + +9.1. Normative References + + [E164] ITU-T, "The International Public Telecommunication + Number Plan", Recommendation E.164, February 2005. + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC3403] Mealling, M., "Dynamic Delegation Discovery System + (DDDS) Part Three: The Domain Name System (DNS) + Database", RFC 3403, October 2002. + + [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform + Resource Identifiers (URI) Dynamic Delegation Discovery + System (DDDS) Application (ENUM)", RFC 3761, + April 2004. + +9.2. Informative References + + [ENUMSERVICE-GUIDE] + Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA + Registration of Enumservices: Guide, Template, and IANA + Considerations", Work in Progress, September 2008. + + [H323] ITU-T, "Packet-based multimedia communications + systems", Recommendation H.323, 2003. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS + UPDATE)", RFC 2136, April 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP): + Locating SIP Servers", RFC 3263, June 2002. + + [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control + Protocol (MGCP) Version 1.0", RFC 3435, January 2003. + + + + + +Lim, et al. Informational [Page 11] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + + [RFC3761bis] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to + Uniform Resource Identifiers (URI) Dynamic Delegation + Discovery System (DDDS) Application (ENUM)", Work + in Progress, February 2008. + + [RFC4114] Hollenbeck, S., "E.164 Number Mapping for the + Extensible Provisioning Protocol (EPP)", RFC 4114, + June 2005. + + [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM + Requirements", RFC 5067, November 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lim, et al. Informational [Page 12] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + +Authors' Addresses + + JoonHyung Lim + National Internet Development Agency of Korea(NIDA) + 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu + Seoul + Korea + + Phone: +82-2-2186-4548 + EMail: jhlim@nida.or.kr + URI: http://www.nida.or.kr + + + Weon Kim + National Internet Development Agency of Korea(NIDA) + 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu + Seoul + Korea + + Phone: +82-2-2186-4502 + EMail: wkim@nida.or.kr + URI: http://www.nida.or.kr + + + ChanKi Park + National Internet Development Agency of Korea(NIDA) + 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu + Seoul + Korea + + Phone: +82-2-2186-4504 + EMail: ckp@nida.or.kr + URI: http://www.nida.or.kr + + + Lawrence Conroy + Roke Manor Research + Roke Manor + Old Salisbury Lane + Romsey + United Kingdom + + Phone: +44-1794-833666 + EMail: lconroy@insensate.co.uk + URI: http://www.sienum.co.uk + + + + + + +Lim, et al. Informational [Page 13] + +RFC 5346 Enum-Based Softswitch Use October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Lim, et al. Informational [Page 14] + |