diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-10.txt similarity index 80% rename from doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt rename to doc/draft/draft-ietf-dnsext-axfr-clarify-10.txt index 94c08ec884..59f7c65435 100644 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-10.txt @@ -1,37 +1,44 @@ -INTERNET-DRAFT Edward Lewis -draft-ietf-dnsext-axfr-clarify-09.txt NeuStar, Inc. -DNSEXT WG July 2008 -Updates: 1034, 1035 (if approved) Intended status: Standards Track +DNS Extensions Working Group Edward Lewis +INTERNET-DRAFT NeuStar, Inc. +Expires: July 1, 2009 January 2009 +Updates: 1034, 1035 (if approved) +Intended status: Standards Track + + DNS Zone Transfer Protocol (AXFR) + draft-ietf-dnsext-axfr-clarify-10.txt - DNS Zone Transfer Protocol (AXFR) Status of this Memo -By submitting this Internet-Draft, each author represents that any -applicable patent or other IPR claims of which he or she is aware -have been or will be disclosed, and any of which he or she becomes -aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. -Internet-Drafts are working documents of the Internet Engineering -Task Force (IETF), its areas, and its working groups. Note that -other groups may also distribute working documents as Internet- -Drafts. + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt. + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -This Internet-Draft will expire on December 31, 2008. + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html Copyright Notice -Copyright (C) The IETF Trust (2008). + Copyright (c) 2008 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with + respect to this document. Abstract @@ -139,7 +146,7 @@ documents. The original "specification" of the AXFR sub-protocol is scattered through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 on page 5 depicts the scenario for which AXFR has been designed. Section 4.3.5 -of RFC 1034 describes the zone synchronisation strategies in general +of RFC 1034 describes the zone synchronization strategies in general and rules for the invocation of a full zone transfer via AXFR; the fifth paragraph of that section contains a very short sketch of the AXFR protocol. Section 3.2.3 of RFC 1035 has assigned the code point @@ -162,13 +169,12 @@ define AXFR as it exists, or is supposed to exist, currently. 2 AXFR Messages -An AXFR message exchange (or session) consists of an AXFR query message -and a set of AXFR response messages. In this document, AXFR client is +An AXFR session consists of an exchange of a AXFR query message and a +set of AXFR response messages. In this document, the AXFR client is the sender of the AXFR query and the AXFR server is the responder. (Use of terms such as master, slave, primary, secondary are not -important to defining the AXFR exchange.) The reason for the imbalance -in number of messages derives from large zones whose contents cannot be -fit into the limited permissible size of a DNS message. +important to defining AXFR.) The use of the word "session" without +qualification refers to an AXFR session. An important aspect to keep in mind is that the definition of AXFR is restricted to TCP [RFC0793]. The design of the AXFR process has @@ -177,7 +183,7 @@ certain inherent features that are not easily ported to UDP [RFC0768]. The basic format of an AXFR message is the DNS message as defined in RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: - "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] -- "Domain Name System (DNS) IANA Considerations" [RFC2929] +- "Domain Name System (DNS) IANA Considerations" [RFC5395] - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] - "Extension Mechanisms for DNS (EDNS0)" [RFC2671] - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] @@ -188,8 +194,11 @@ RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] The upper limit on the permissible size of a DNS message over TCP is -defined in RFC 1035, section 4.2.2. Unlike DNS messages over UDP, -this limit is not changed by EDNS0. +only restricted by the TCP framing defined in RFC 1035, section 4.2.2 +which specifies a two-octet message length field, understood to be +unsigned, and thus causing a limit of 65535 octets. Unlike DNS +messages over UDP, this limit is not changed by EDNS0. + Field names used in this document will correspond to the names as they appear in the IANA registry for DNS Header Flags [DNSFLGS]. @@ -294,7 +303,7 @@ additional section might change over time. If either a change to an existing resource record (like the OPT RR for EDNS0) is made or a new additional section record is created, the new definitions ought to include a discussion on the impact upon AXFR. Although this is not -predictale, future additional section residing records may have an +predictable, future additional section residing records may have an effect that is orthogonal to AXFR, so can ride through the session as opaque data. In this case, a "wise" implementation ought to be able to pass these records through without disruption. @@ -323,7 +332,8 @@ necessary. An AXFR client might receive a number of AXFR response messages free of an error condition before the message indicating an error is received. But once an error is reported, the AXFR client can -assume that the error reporting message is the last. +assume that the error reporting message is the last message sent by +the AXFR server in the current AXFR session. 2.2.1 "0 Message" Response @@ -333,33 +343,16 @@ is unhealthy for there to be 0 responses in a protocol that is designed around a query - response paradigm over an unreliable transport. The lack of a response could be a sign of underlying network problems and cause the protocol state machine to react accordingly. However, AXFR -uses TCP and not UDP, eliminating undetected network errors. +uses TCP and not UDP, eliminating undetectable network errors. A "0 message response" is reserved for situations in which the server has a reason to suspect that the query is sent for the purpose of abuse. Due to the use of this being so controversial, a "0 message response" is not being defined as a legitimate part of the protocol -but the use of it is being acknowledge as a warning to AXFR client +but the use of it is being acknowledged as a warning to AXFR client implementations. Any earnest query has the expectation of some response but may not get one. -If an AXFR client sends a query on a TCP connection and the connection -is closed at any point, the AXFR client MUST consider the session -terminated. The message ID MAY be used again on a new connection, -even if the question and AXFR server are the same. Facing a dropped -connection a client SHOULD try to make some determination whether the -connection closure was the result of network activity or a decision -by the AXFR server. This determination is not an exact science. It -is up to the AXFR client implementor to react, but the reaction -SHOULD NOT be an endless cycle of retires nor an increasing (in -frequency) retry rate. - -An AXFR server implementor SHOULD take into consideration what this -dilemma described above when a connection is closed with an outstanding -query in the pipeline. For this reason, a server ought to reserve -this course of action for situations in which it believes beyond a -doubt that the AXFR client is attemping abusive behavior. - 2.2.2 Header Values ID See note 2.2.2.a @@ -446,11 +439,14 @@ resource records appearing in the additional section. See Section 2.2.3 Query Section In the first response message, this section MUST be copied from the -query. In subsequent messages this section MAY be copied from the -query, MAY be empty. The content of this section MAY be used to +query. In subsequent messages, this section MAY be copied from the +query or it MAY be empty. The content of this section MAY be used to determine the context of the message, that is, the name of the zone being transferred. +>| [...]. In subsequent messages, this section MAY be copied from the +>| query, or it MAY be empty. [...] + 2.2.4 Answer Section MUST be populated with the zone contents. See later section on @@ -460,7 +456,7 @@ encoding zone contents. MUST be empty. -2.2.5 Additional Section +2.2.6 Additional Section The contents of this section MUST follow the guidelines for EDNS0, TSIG, SIG(0), or what ever other future record is possible here. The @@ -469,10 +465,29 @@ contents of section 2.1.5 apply here as well. Note that TSIG and SIG(0), if in use, will treat each individual AXFR response message within a session as a unit of data. That is, each message will have a TSIG or SIG(0) (if in use) and the -crytpographic check will cover just that message. The same rule +cryptographic check will cover just that message. The same rule will apply to future alternatives and documents covering them ought to consider the impact on AXFR response messages. +2.3 TCP Connection Aborts + +If an AXFR client sends a query on a TCP connection and the connection +is closed at any point, the AXFR client MUST consider the AXFR session +terminated. The message ID MAY be used again on a new connection, +even if the question and AXFR server are the same. Facing a dropped +connection a client SHOULD try to make some determination whether the +connection closure was the result of network activity or a decision +by the AXFR server. This determination is not an exact science. It +is up to the AXFR client implementor to react, but the reaction +SHOULD NOT be an endless cycle of retries nor an increasing (in +frequency) retry rate. + +An AXFR server implementor SHOULD take into consideration the dilemma +described above when a connection is closed with an outstanding query +in the pipeline. For this reason, a server ought to reserve this +course of action for situations in which it believes beyond a doubt +that the AXFR client is attempting abusive behavior. + 3 Zone Contents The objective of the AXFR session is to request and transfer the @@ -497,7 +512,11 @@ records as will fit within a DNS message. Zones for which it is impractical to list the entire zones for a serial number (because changes happen too quickly) are not suitable for AXFR -retrieval. +retrieval. A typical (but not limiting) description of such a zone +is a zone consisting of responses generated via other database lookups +and/or computed based upon ever changing data. In essence, if the +zone changes (on average) more frequently than and AXFR session can be +finished, the zone is not a good candidate for AXFR. 3.2 Delegation Records @@ -511,11 +530,12 @@ included in a zone transfer. The phrase "that describe cuts" is a reference to the NS set and applicable glue records. It does not mean that the cut points and the apex resource records are identical. For example, the SOA resource -record is only found at the apex, as well as a slew of DNSSEC resource -records. There are also some DNSSEC resource record sets that are -explicitly different between the cut point and the apex. The -discussion here is restricted to just the NS resource record set and -glue as these "describe cuts." +record is only found at the apex, as well as DNSSEC resource records. +The is even a DNSSEC resource record found only at the zone cut and not +at the corresponding apex. There are also some DNSSEC resource record +sets that are explicitly different between the cut point and the apex. +The discussion here is restricted to just the NS resource record set +and glue as these "describe cuts." The issue is that in operations there are times when the NS resource records for a zone might be different at a cut point in the parent and @@ -525,7 +545,7 @@ protocol is robust enough to overcome inconsistencies up to (but not including) there being no parent indicated NS resource record referencing a server that is able to serve the child zone. This robustness is one quality that has fueled the success of the DNS. -Still, the inconsistency is a error state and steps need to be taken +Still, the inconsistency is an error state and steps need to be taken to make it apparent (if it is unplanned) and to make it clear once the inconsistency has been removed. @@ -538,7 +558,7 @@ the cut point. The question that arises is, when facing a situation in which a cut point's NS resource records do not match the authoritative set, whether an AXFR server responds with the NS resource record set that is in the -zone or is at the authoritative location. +zone being transferred or is at the authoritative location. The AXFR response MUST contain the cut point NS resource record set registered with the zone whether it agrees with the authoritative set @@ -567,7 +587,7 @@ in a registration database. 4) Beginning with an error state of two servers for a zone having inconsistent zone contents for a given zone serial number, if a client -requests and recieves an IXFR transfer from one server followed by +requests and receives an IXFR transfer from one server followed by another IXFR transfer from the other server, the client can encounter an IXFR protocol error state where an attempt is made to incrementally add a record that already exists or to delete a record that does not @@ -578,7 +598,7 @@ it relates. A nudge for updated text on this.) 3.3 Glue Records -As quoted in the previous section, RFC 1034, section 4.2.1, provides +As quoted in the previous section, section 4.2.1 of RFC 1034 provides guidance and rationale for the inclusion of glue records as part of an AXFR transfer. And, as also argued in the previous section of this document, even when there is an inconsistency between the address in a @@ -586,7 +606,7 @@ glue record and the authoritative copy of the name server's address, the glue resource record that is registered as part of the zone for that serial number is to be included. -This applies for glue records for any address family. +This applies to glue records for any address family [RFC1700]. The AXFR response MUST contain the appropriate glue records as registered with the zone. The interpretation of "registered with" @@ -615,12 +635,12 @@ Compression." 3.5 Occluded Names -Dynamic Update [RFC2136] (and including DNAME [2672]) operations can +Dynamic Update [RFC2136] (and including DNAME [RFC2672]) operations can have a side effect of occluding names in a zone. The addition of a delegation point via dynamic update will render all subordinate domain -names to be in a limbo, still part of the zone but not available for to -the look up process. The addition of a DNAME resource record set has -the same impact. The subordinate names are said to be "occluded." +names to be in a limbo, still part of the zone but not available +to the lookup process. The addition of a DNAME resource record has the +same impact. The subordinate names are said to be "occluded." Occluded names MUST be included in AXFR responses. An AXFR client MUST be able to identify and handle occluded names. The rationale for this @@ -631,20 +651,20 @@ was in error and is to be undone. AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC 1034 that states: "Because accuracy is essential, TCP or some other -reliable protocol must be used for AXFR requests." The most common -scenario is for an AXFR client to open a TCP connection to the AXFR -server, send an AXFR query, receive the AXFR response, and then -close the connection. There are variations on this, such as a query -for the zone's SOA resource record first, and so on. +reliable protocol must be used for AXFR requests." The restriction to +TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet +Hosts - Application and Support" [RFC1123]. -Two issues have emerged since the original specification of AXFR. -One is that lack of specificity has yielded some implementations -that assume the TCP connection is dedicated to the single AXFR -session, which has led to implementation choices that prevent either -multiple concurrent zone transfers or the use of the open connection -for other queries. The other issue is the prospect of using UDP as a -transport has come to look promising because of trends in the past -two decades. +The most common scenario is for an AXFR client to open a TCP connection +to the AXFR server, send an AXFR query, receive the AXFR response, and +then close the connection. There are variations on this, such as a +query for the zone's SOA resource record first, and so on. Note that +this is documented as a most common scenario. + +The assumption that a TCP connection is dedicated to the single AXFR +session is incorrect, this as has led to implementation choices that +prevent either multiple concurrent zone transfers or the use of the +open connection for other queries. Being able to have multiple concurrent zone transfers is considered desirable by operators who have sets of name servers that are @@ -690,10 +710,11 @@ reason. An AXFR client SHOULD close the connection when there is no apparent need to use the connection for some time period. The AXFR server ought not have to maintain idle connections, the burden of connection closure ought to be on the client. Apparent need for -the connection is a judgement for the AXFR client and the DNS -client. If the connection is used for multiple sessions, or it is -known sessions will be coming or is there is other query/response -traffic on the open connection, that is "apparent need." +the connection is a judgment for the AXFR client and the DNS +client. If the connection is used for multiple sessions, or if it is +known sessions will be coming or if there is other query/response +traffic anticipated or currently on the open connection, then there +is "apparent need." An AXFR client MAY cancel delivery of a zone only by closing the connection. However, this action will also cancel all other outstanding @@ -719,7 +740,7 @@ opening a new connection. (Non-AXFR session traffic can also use an open connection.) If in doing so the AXFR client realizes that the responses cannot be properly differentiated (lack of matching query IDs for example) or the connection is terminated for a remote -reason, then the AXFR client SHOULD not attempt to reuse an open +reason, then the AXFR client SHOULD NOT attempt to reuse an open connection with the specific AXFR server until the AXFR server is updated (which is of course, not an event captured in the DNS protocol). @@ -758,8 +779,7 @@ serving AXFR. All reasons are arguable, but the fact remains that there is a requirement to provide mechanisms to restrict AXFR. A DNS implementation SHOULD provide means to restrict AXFR sessions to -specific clients. By default, a DNS implementation SHOULD only allow -the designated authoritative servers to have access to the zone. +specific clients. An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address @@ -777,10 +797,32 @@ all AXFR requests. I.e., an operator ought to be able to allow any AXFR query to be granted. A general purpose implementation SHOULD NOT have a default policy -for AXFR requests to be "open to all." +for AXFR requests to be "open to all." For example, a default could +be to restrict transfers to loopback address(es) and such. 6 Zone Integrity +An AXFR client MUST ensure that only a successfully transferred +copy of the zone data can be used to serve this zone. Previous +description and implementation practice have introduced a two-stage +model of the whole zone synchronization procedure: Upon a trigger +event (e.g., polling of SOA resource record detects change in the +SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session +is initiated, whereby the zone data are saved in a zone file or +data base (this latter step is necessary anyway to ensure proper +restart of the server); upon successful completion of the AXFR +operation and some sanity checks, this data set is 'loaded' and +made available for serving the zone in an atomic operation, and +flagged 'valid' for use during the next restart of the DNS server; +if any error is detected, this data set MUST be deleted, and the +AXFR client MUST continue to serve the previous version of the zone, +if it did before. The externally visible behavior of an AXFR client +implementation MUST be equivalent to that of this two-stage model. + +If a server rejects data contained in an AXFR session, the server +SHOULD remember the serial number and not attempt to retrieve the +same zone version again. + Ensuring that an AXFR client does not accept a forged copy of a zone is important to the security of a zone. If a zone operator has the opportunity, protection can be afforded via dedicated links, physical @@ -794,7 +836,34 @@ Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the contents. These techniques MAY also be used for authorization. -7 Backwards Compatibility +7 Zone Expiry Timer + +Section 4.3.5 of RFC 1034 contains the following paragraph: + +"The periodic polling of the secondary servers is controlled by +parameters in the SOA RR for the zone, which set the minimum acceptable +polling intervals. The parameters are called REFRESH, RETRY, and +EXPIRE. Whenever a new zone is loaded in a secondary, the secondary +waits REFRESH seconds before checking with the primary for a new serial. +If this check cannot be completed, new checks are started every RETRY +seconds. The check is a simple query to the primary for the SOA RR of +the zone. If the serial field in the secondary's zone copy is equal to +the serial returned by the primary, then no changes have occurred, and +the REFRESH interval wait is restarted. If the secondary finds it +impossible to perform a serial check for the EXPIRE interval, it must +assume that its copy of the zone is obsolete an discard it." + +Perhaps what is not clear in the paragraph regarding the EXPIRE +interval timer is that it is only reset to the EXPIRE parameter when +a new zone is loaded. A new zone means a zone with a higher serial +number than the most recently loaded zone. The EXPIRE interval timer +is not reset automatically as a result of a zone transfer as a zone +could be (mistakenly) transferred with the same or lower serial number. + +I.e., successively transferring a zone from server to server does not +permit the zone to avoid expiration. + +8 Backwards Compatibility Describing backwards compatibility is difficult because of the lack of specifics in the original definition. In this section some hints at @@ -813,7 +882,7 @@ implementation SHOULD, in it's documentation, encourage operators to periodically review AXFR clients and servers it has made notes about as old software periodically gets updated. -7.1 Server +8.1 Server An AXFR server has the luxury of being able to react to an AXFR client's abilities with the exception of knowing if the client can @@ -825,7 +894,7 @@ An implementation of an AXFR server SHOULD permit configuring, on a per AXFR client basis, a need to revert to single resource record per message. The default SHOULD be to use multiple records per message. -7.2 Client +8.2 Client An AXFR client has the opportunity to try extensions when querying an AXFR server. @@ -836,23 +905,23 @@ and SHOULD take into consideration whether the AXFR server intends to close the connection immediately upon completion of the original (connection-causing) zone transfer. -8 Security Considerations +9 Security Considerations Concerns regarding authorization, traffic flooding, and message integrity are mentioned in "Authorization" (section 5), "TCP" (section -4.2) and Zone Integrity (section 6). +4.2) and "Zone Integrity" (section 6). -9 IANA Considerations +10 IANA Considerations No new registries or new registrations are included in this document. -10 Internationalization Considerations +11 Internationalization Considerations It is assumed that supporting of international domain names has been solved via "Internationalizing Domain Names in Applications (IDNA)" [RFC3490]. -11 Acknowledgements +12 Acknowledgements Earlier editions of this document have been edited by Andreas Gustafsson. In his latest version, this acknowledgement appeared. @@ -868,15 +937,15 @@ Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, ... -12 References +13 References -All references prefixed by "RFC" can be obtained from the RFC Editor, +All references prefixed by "RFC" can be obtained from the RFC Editor +web site at the URLs: http://rfc-editor.org/rfc.html +or http://rfc-editor.org/rfcsearch.html ; information regarding this organization can be found at the following -URL: - http://rfc-editor.org/ -Additionally, these documents can be obtained via the IETF web site. +URL: http://rfc-editor.org/ -12.1 Normative +13.1 Normative [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. @@ -886,6 +955,8 @@ Additionally, these documents can be obtained via the IETF web site. STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. +[RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone @@ -900,9 +971,8 @@ Additionally, these documents can be obtained via the IETF web site. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. -[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, RFC - 2929, September 2000. +[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations", + BCP 42, RFC 5395, November 2008. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures @@ -925,10 +995,12 @@ Additionally, these documents can be obtained via the IETF web site. [DNSFLGS] http://www.iana.org/assignments/dns-header-flags [DNSVALS] http://www.iana.org/assignments/dns-parameters -12.2 Informative +13.2 Informative [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. +[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700, + October 1994. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. @@ -936,7 +1008,7 @@ Additionally, these documents can be obtained via the IETF web site. "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. -13 Editor's Address +14 Editor's Address Edward Lewis 46000 Center Oak Plaza @@ -944,49 +1016,7 @@ Sterling, VA, 22033, US +1-571-434-5468 ed.lewis@neustar.biz -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. - Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). - -