diff options
Diffstat (limited to 'doc/rfc/rfc3403.txt')
| -rw-r--r-- | doc/rfc/rfc3403.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc3403.txt b/doc/rfc/rfc3403.txt new file mode 100644 index 0000000..fb08047 --- /dev/null +++ b/doc/rfc/rfc3403.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Mealling +Request for Comments: 3403 VeriSign +Obsoletes: 2915, 2168 October 2002 +Category: Standards Track + + + Dynamic Delegation Discovery System (DDDS) + Part Three: The Domain Name System (DNS) Database + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document describes a Dynamic Delegation Discovery System (DDDS) + Database using the Domain Name System (DNS) as a distributed database + of Rules. The Keys are domain-names and the Rules are encoded using + the Naming Authority Pointer (NAPTR) Resource Record (RR). + + Since this document obsoletes RFC 2915, it is the official + specification for the NAPTR DNS Resource Record. It is also part of + a series that is completely specified in "Dynamic Delegation + Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). + It is very important to note that it is impossible to read and + understand any document in this series without reading the others. + + + + + + + + + + + + + + + + + +Mealling Standards Track [Page 1] + +RFC 3403 DDDS DNS Database October 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. DDDS Database Specification . . . . . . . . . . . . . . . . 3 + 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2 Additional Information Processing . . . . . . . . . . . . . 7 + 4.2.1 Additional Section processing by DNS servers . . . . . . . . 7 + 4.2.2 Additional Section processing by resolver/applications . . . 7 + 4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 7 + 5. Application Specifications . . . . . . . . . . . . . . . . . 8 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. Advice for DNS Administrators . . . . . . . . . . . . . . . 10 + 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 11 + References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + The Dynamic Delegation Discovery System (DDDS) is used to implement + lazy binding of strings to data, in order to support dynamically + configured delegation systems. The DDDS functions by mapping some + unique string to data stored within a DDDS Database by iteratively + applying string transformation rules until a terminal condition is + reached. + + This document describes the way in which the Domain Name System (DNS) + is used as a data store for the Rules that allow a DDDS Application + to function. It does not specify any particular application or usage + scenario. The entire series of documents is specified in "Dynamic + Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" + (RFC 3401) [1]. It is very important to note that it is impossible + to read and understand any document in that series without reading + the related documents. + + The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) + specified here was originally produced by the URN Working Group as a + way to encode rule-sets in DNS so that the delegated sections of a + Uniform Resource Identifiers (URI) could be decomposed in such a way + that they could be changed and re-delegated over time. The result + was a Resource Record that included a regular expression that would + be used by a client program to rewrite a string into a domain name. + + + +Mealling Standards Track [Page 2] + +RFC 3403 DDDS DNS Database October 2002 + + + Regular expressions were chosen for their compactness to expressivity + ratio allowing for a great deal of information to be encoded in a + rather small DNS packet. + + Over time this process was generalized for other Applications and + Rule Databases. This document defines a Rules Database absent any + particular Application as there may be several Applications all + taking advantage of this particular Rules Database. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [6]. + + All other terminology, especially capitalized terms, is taken from + [3]. + +3. DDDS Database Specification + + General Description: + This database uses the Domain Name System (DNS) as specified in + [8] and [7]. + + The character set used to specify the various values of the NAPTR + records is UTF-8 [17]. Care must be taken to ensure that, in the + case where either the input or the output to the substitution + expression contains code points outside of the ASCII/Unicode + equivalence in UTF-8, any UTF-8 is interpreted as a series of + code-points instead of as a series of bytes. This is to ensure + that the internationalized features of the POSIX Extended Regular + Expressions are able to match their intended code-points. + Substitution expressions MUST NOT be written where they depend on + a specific POSIX locale since this would cause substitution + expressions to loose their ability to be universally applicable. + + All DNS resource records have a Time To Live (TTL) associated with + them. When the number of seconds has passed since the record was + retrieved the record is no longer valid and a new query must be + used to retrieve the new records. Thus, as mentioned in the DDDS + Algorithm, there can be the case where a given Rule expires. In + the case where an application attempts to fall back to previously + retrieved sets of Rules (either in the case of a bad delegation + path or some network or server failure) the application MUST + ensure that none of the records it is relying on have expired. In + the case where even a single record has expired, the application + is required to start over at the beginning of the algorithm. + + + + +Mealling Standards Track [Page 3] + +RFC 3403 DDDS DNS Database October 2002 + + + Key Format: + A Key is a validly constructed DNS domain-name. + + Lookup Request: + In order to request a set of rules for a given Key, the client + issues a request, following standard DNS rules, for NAPTR Resource + Records for the given domain-name. + + Lookup Response: + The response to a request for a given Key (domain-name) will be a + series of NAPTR records. The format of a NAPTR Resource Record + can be found in Section 4. + + Rule Insertion Procedure: + Rules are inserted by adding new records to the appropriate DNS + zone. If a Rule produces a Key that exists in a particular zone + then only the entity that has administrative control of that zone + can specify the Rule associated with that Key. + + Collision Avoidance: + In the case where two Applications may use this Database (which is + actually the case with the ENUM and URI Resolution Applications, + Section 6.2), there is a chance of collision between rules where + two NAPTR records appear in the same domain but they apply to more + than one Application. There are three ways to avoid collisions: + + * create a new zone within the domain in common that contains + only NAPTR records that are appropriate for the application. + E.g., all URI Resolution records would exist under + urires.example.com and all ENUM records would be under + enum.example.com. In the case where this is not possible due + to lack of control over the upstream delegation the second + method is used. + + * write the regular expression such that it contains enough of + the Application Unique string to disambiguate it from any + other. For example, the URI Resolution Application would be + able to use the scheme name on the left hand side to anchor the + regular expression match to that scheme. An ENUM specific + record in that same zone would be able to anchor the left hand + side of the match with the "+" character which is defined by + ENUM to be at the beginning of every Application Unique String. + This way a given Application Unique String can only match one + or the other record, not both. + + * if two Application use different Flags or Services values then + a record from another Application will be ignored since it + doesn't apply to the Services/Flags in question. + + + +Mealling Standards Track [Page 4] + +RFC 3403 DDDS DNS Database October 2002 + + +4. NAPTR RR Format + +4.1 Packet Format + + The packet format of the NAPTR RR is given below. The DNS type code + for NAPTR is 35. + + The packet format for the NAPTR record is as follows + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ORDER | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PREFERENCE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / FLAGS / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / SERVICES / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / REGEXP / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / REPLACEMENT / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + <character-string> and <domain-name> as used here are defined in RFC + 1035 [7]. + + ORDER + A 16-bit unsigned integer specifying the order in which the NAPTR + records MUST be processed in order to accurately represent the + ordered list of Rules. The ordering is from lowest to highest. + If two records have the same order value then they are considered + to be the same rule and should be selected based on the + combination of the Preference values and Services offered. + + PREFERENCE + Although it is called "preference" in deference to DNS + terminology, this field is equivalent to the Priority value in the + DDDS Algorithm. It is a 16-bit unsigned integer that specifies + the order in which NAPTR records with equal Order values SHOULD be + processed, low numbers being processed before high numbers. This + is similar to the preference field in an MX record, and is used so + domain administrators can direct clients towards more capable + hosts or lighter weight protocols. A client MAY look at records + with higher preference values if it has a good reason to do so + such as not supporting some protocol or service very well. + + + + +Mealling Standards Track [Page 5] + +RFC 3403 DDDS DNS Database October 2002 + + + The important difference between Order and Preference is that once + a match is found the client MUST NOT consider records with a + different Order but they MAY process records with the same Order + but different Preferences. The only exception to this is noted in + the second important Note in the DDDS algorithm specification + concerning allowing clients to use more complex Service + determination between steps 3 and 4 in the algorithm. Preference + is used to give communicate a higher quality of service to rules + that are considered the same from an authority standpoint but not + from a simple load balancing standpoint. + + It is important to note that DNS contains several load balancing + mechanisms and if load balancing among otherwise equal services + should be needed then methods such as SRV records or multiple A + records should be utilized to accomplish load balancing. + + FLAGS + A <character-string> containing flags to control aspects of the + rewriting and interpretation of the fields in the record. Flags + are single characters from the set A-Z and 0-9. The case of the + alphabetic characters is not significant. The field can be empty. + + It is up to the Application specifying how it is using this + Database to define the Flags in this field. It must define which + ones are terminal and which ones are not. + + SERVICES + A <character-string> that specifies the Service Parameters + applicable to this this delegation path. It is up to the + Application Specification to specify the values found in this + field. + + REGEXP + A <character-string> containing a substitution expression that is + applied to the original string held by the client in order to + construct the next domain name to lookup. See the DDDS Algorithm + specification for the syntax of this field. + + As stated in the DDDS algorithm, The regular expressions MUST NOT + be used in a cumulative fashion, that is, they should only be + applied to the original string held by the client, never to the + domain name produced by a previous NAPTR rewrite. The latter is + tempting in some applications but experience has shown such use to + be extremely fault sensitive, very error prone, and extremely + difficult to debug. + + + + + + +Mealling Standards Track [Page 6] + +RFC 3403 DDDS DNS Database October 2002 + + + REPLACEMENT + A <domain-name> which is the next domain-name to query for + depending on the potential values found in the flags field. This + field is used when the regular expression is a simple replacement + operation. Any value in this field MUST be a fully qualified + domain-name. Name compression is not to be used for this field. + + This field and the REGEXP field together make up the Substitution + Expression in the DDDS Algorithm. It is simply a historical + optimization specifically for DNS compression that this field + exists. The fields are also mutually exclusive. If a record is + returned that has values for both fields then it is considered to + be in error and SHOULD be either ignored or an error returned. + +4.2 Additional Information Processing + + Additional section processing requires upgraded DNS servers, thus it + will take many years before applications can expect to see relevant + records in the additional information section. + +4.2.1 Additional Section Processing by DNS Servers + + DNS servers MAY add RRsets to the additional information section that + are relevant to the answer and have the same authenticity as the data + in the answer section. Generally this will be made up of A and SRV + records but the exact records depends on the application. + +4.2.2 Additional Section Processing by Resolver/Applications + + Applications MAY inspect the Additional Information section for + relevant records but Applications MUST NOT require that records of + any type be in the Additional Information section of any DNS response + in order for clients to function. All Applications must be capable + of handling responses from nameservers that never fill in the + Additional Information part of a response. + +4.3 Master File Format + + The master file format follows the standard rules in RFC-1035. Order + and preference, being 16-bit unsigned integers, shall be an integer + between 0 and 65535. The Flags and Services and Regexp fields are + all quoted <character-string>s. Since the Regexp field can contain + numerous backslashes and thus should be treated with care. See + Section 7 for how to correctly enter and escape the regular + expression. + + + + + + +Mealling Standards Track [Page 7] + +RFC 3403 DDDS DNS Database October 2002 + + +5. Application Specifications + + This DDDS Database is usable by any application that makes use of the + DDDS algorithm. In addition to the items required to specify a DDDS + Application, an application wishing to use this Database must also + define the following values: + + o What domain the Key that is produced by the First Well Known Rule + belongs to. Any application must ensure that its rules do not + collide with rules used by another application making use of this + Database. For example, the 'foo' application might have all of + its First Well Known Keys be found in the 'foo.net' zone. + + o What the allowed values for the Services and Protocols fields are. + + o What the expected output is of the terminal rewrite rule in + addition to how the Flags are actually encoded and utilized. + +6. Examples + +6.1 URN Example + + The NAPTR record was originally created for use with the Uniform + Resource Name (URN) Resolver Discovery Service (RDS) [15]. This + example details how a particular URN would use the NAPTR record to + find a resolver service that can answer questions about the URN. See + [2] for the definitive specification for this Application. + + Consider a URN namespace based on MIME Content-Ids (this is very + hypothetical so do not rely on this). The URN might look like this: + + urn:cid:199606121851.1@bar.example.com + + This Application's First Well Known Rule is to extract the characters + between the first and second colon. For this URN that would be + 'cid'. The Application also specifies that, in order to build a + Database-valid Key, the string 'urn.arpa' should be appended to the + result of the First Well Known Rule. The result is 'cid.urn.arpa'. + Next, the client queries the DNS for NAPTR records for the domain- + name 'cid.urn.arpa'. The result is a single record: + +cid.urn.arpa. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . + + + + + + + +Mealling Standards Track [Page 8] + +RFC 3403 DDDS DNS Database October 2002 + + + Since there is only one record, ordering the responses is not a + problem. The replacement field is empty, so the pattern provided in + the regexp field is used. We apply that regexp to the entire URN to + see if it matches, which it does. The \2 part of the substitution + expression returns the string "example.com". Since the flags field + is empty, the lookup is not terminal and our next probe to DNS is for + more NAPTR records where the new domain is 'example.com'. + + Note that the rule does not extract the full domain name from the + CID, instead it assumes the CID comes from a host and extracts its + domain. While all hosts, such as 'bar', could have their very own + NAPTR, maintaining those records for all the machines at a site could + be an intolerable burden. Wildcards are not appropriate here since + they only return results when there is no exactly matching names + already in the system. + + The record returned from the query on "example.com" might look like: + +example.com. +;; order pref flags service regexp replacement +IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. +IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. +IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. + + Continuing with the example, note that the values of the order and + preference fields are equal in all records, so the client is free to + pick any record. The Application defines the flag 'a' to mean a + terminal lookup and that the output of the rewrite will be a domain- + name for which an A record should be queried. Once the client has + done that, it has the following information: the host, its IP + address, the protocol, and the services available via that protocol. + Given these bits of information the client has enough to be able to + contact that server and ask it questions about the URN. + + Recall that the regular expression used \2 to extract a domain name + from the CID, and \. for matching the literal '.' characters + separating the domain name components. Since '\' is the escape + character, literal occurrences of a backslash must be escaped by + another backslash. For the case of the cid.urn.arpa record above, + the regular expression entered into the master file should be + "!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code + actually receives the record, the pattern will have been converted to + "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i". + + + + + + + + +Mealling Standards Track [Page 9] + +RFC 3403 DDDS DNS Database October 2002 + + +6.2 E164 Example + + The ENUM Working Group in the IETF has specified a service that + allows a telephone number to be mapped to a URI [18]. The + Application Unique String for the ENUM Application is the E.164 + telephone number with the dashes removed. The First Well Known Rule + is to remove all characters from the the telephone number and then + use the entire number as the first Key. For example, the phone + number "770-555-1212" represented as an E.164 number would be "+1- + 770-555-1212". Converted to the Key it would be "17705551212". + + The ENUM Application at present only uses this Database. It + specifies that, in order to convert the first Key into a form valid + for this Database, periods are inserted between each digit, the + entire Key is inverted and then "e164.arpa" is appended to the end. + The above telephone number would then read + "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to + retrieve Rewrite Rules as NAPTR records. + + For this example telephone number we might get back the following + NAPTR records: + +$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. + IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . + IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" . + + Both the ENUM [18] and URI Resolution [4] Applications use the 'u' + flag. This flag states that the Rule is terminal and that the output + is a URI which contains the information needed to contact that + telephone service. ENUM also uses the same format for its Service + Parameters. These state that the available protocols used to access + that telephone's service are either the Session Initiation Protocol + or SMTP mail. + +7. Advice for DNS Administrators + + Beware of regular expressions. Not only are they difficult to get + correct on their own, but there is the previously mentioned + interaction with DNS. Any backslashes in a regexp must be entered + twice in a zone file in order to appear once in a query response. + More seriously, the need for double backslashes has probably not been + tested by all implementors of DNS servers. + + + + + + + + + +Mealling Standards Track [Page 10] + +RFC 3403 DDDS DNS Database October 2002 + + + In order to mitigate zone file problems, administrators should + encourage those writing rewrite rules to utilize the 'default + delimiter' feature of the regular expression. In the DDDS + specification the regular expression starts with the character that + is to be the delimiter. Hence if the first character of the regular + expression is an exclamation mark ('!') for example then the regular + expression can usually be written with fewer backslashes. + +8. Notes + + A client MUST process multiple NAPTR records in the order specified + by the "order" field, it MUST NOT simply use the first record that + provides a known Service Parameter combination. + + When multiple RRs have the same "order" and all other criteria being + equal, the client should use the value of the preference field to + select the next NAPTR to consider. However, because it will often be + the case where preferred protocols or services exist, clients may use + this additional criteria to sort the records. + + If the lookup after a rewrite fails, clients are strongly encouraged + to report a failure, rather than backing up to pursue other rewrite + paths. + +9. IANA Considerations + + The values for the Services and Flags fields will be determined by + the Application that makes use of this DDDS Database. Those values + may require a registration mechanism and thus may need some IANA + resources. This specification by itself does not. + +10. Security Considerations + + The NAPTR record, like any other DNS record, can be signed and + validated according to the procedures specified in DNSSEC. + + This Database makes identifiers from other namespaces subject to the + same attacks as normal domain names. Since they have not been easily + resolvable before, this may or may not be considered a problem. + + Regular expressions should be checked for sanity, not blindly passed + to something like PERL since arbitrary code can be included and + subsequently processed. + + + + + + + + +Mealling Standards Track [Page 11] + +RFC 3403 DDDS DNS Database October 2002 + + +References + + [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + One: The Comprehensive DDDS", RFC 3401, October 2002. + + [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Two: The Algorithm", RFC 3402, October 2002. + + [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, October + 2002. + + [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Four: The Uniform Resource Identifiers (URI) Resolution + Application", RFC 3404, October 2002. + + [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [8] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", + RFC 2234, November 1997. + + [11] Daniel, R., "A Trivial Convention for using HTTP in URN + Resolution", RFC 2169, June 1997. + + [12] IEEE, "IEEE Standard for Information Technology - Portable + Operating System Interface (POSIX) - Part 2: Shell and Utilities + (Vol. 1)", IEEE Std 1003.2-1992, January 1993. + + [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [14] Moats, R., "URN Syntax", RFC 2141, May 1997. + + + + + +Mealling Standards Track [Page 12] + +RFC 3403 DDDS DNS Database October 2002 + + + [15] Sollins, K., "Architectural Principles of Uniform Resource Name + Resolution", RFC 2276, January 1998. + + [16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource + Identifiers using the Domain Name System", RFC 2168, June 1997. + + [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. + +Author's Address + + Michael Mealling + VeriSign + 21345 Ridgetop Circle + Sterling, VA 20166 + US + + EMail: michael@neonym.net + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mealling Standards Track [Page 13] + +RFC 3403 DDDS DNS Database October 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Mealling Standards Track [Page 14] + |