idnits 2.17.1 draft-ietf-urn-dns-ddds-database-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2915, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 323 has weird spacing: '... regexp repla...' -- 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 (February 2000) is 8808 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) -- Looks like a reference, but probably isn't: 'A-Z0-9' on line 208 == Unused Reference: '4' is defined on line 448, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 452, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 455, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 458, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 462, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 466, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2141 (ref. '9') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '10') == Outdated reference: A later version (-07) exists of draft-ietf-urn-ddds-00 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-00 ** Obsolete normative reference: RFC 2915 (ref. '13') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2168 (ref. '14') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Mealling 2 Internet-Draft Verisign 3 Expires: August 1, 2000 February 2000 5 A DDDS Database Using The Domain Name System 6 draft-ietf-urn-dns-ddds-database-03 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 This Internet-Draft will expire on August 1, 2000. 28 Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 Abstract 34 This document describes a Dynamic Delegation Discovery System 35 Database using the Domain Name System as a distributed database of 36 Rules. The Keys are domain-names and the Rules are encoded using the 37 NAPTR Resource Record. 39 Since this document officially obsoletes RFC 2915, it is the 40 official specification for the NAPTR DNS Resource Record. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 3. DDDS Database Specification . . . . . . . . . . . . . . . . . 5 47 4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . . 7 48 4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 7 49 4.2 Master File Format . . . . . . . . . . . . . . . . . . . . . . 9 50 5. Application Specifications . . . . . . . . . . . . . . . . . . 10 51 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 52 6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 53 6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 54 7. Advice for DNS Administrators . . . . . . . . . . . . . . . . 14 55 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 57 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 62 1. Introduction 64 The NAPTR DNS Resource Record was originally produced by the URN 65 Working Group as a way to encode rule-sets in DNS so that the 66 delegated sections of a URI could be decomposed in such a way that 67 they could be changed and re-delegated over time. The result was a 68 Resource Record that included a regular expression that would be 69 used by a client program to rewrite a string into a domain name. 70 Regular expressions were chosen for their compactness to 71 expressivity ratio allowing for a great deal of information to be 72 encoded in a rather small DNS packet. 74 Over time this process was generalized for other Applications and 75 Rule Databases. This document defines a Rules Database absent any 76 particular Application as there may be several Applications all 77 taking advantage of this particular Rules Database. 79 As a result of this generalization, this document, along with RFC 80 ZZZZ[11] and RFC XXXX[12], obsoletes RFC 2168[14], RFC 2915[13] and 81 updates RFC 2276[10]. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 87 this document are to be interpreted as described in [1]. 89 All other terminology, especially capitalized terms, is taken from 90 [11]. 92 3. DDDS Database Specification 94 General Description: 95 This database uses the Domain Name System (DNS) as specified in 96 [3] and [2]. The character set used to specify the various values 97 of the NAPTR records is UTF-8[15]. 99 Key Format: 100 A Key is a validly constructed DNS domain-name. 102 Lookup Request: 103 In order to request a set of rules for a given Key, the client 104 issues a request, following standard DNS rules, for NAPTR 105 Resource Records for the given domain-name. 107 Lookup Response: 108 The response to a request for a given Key (domain-name) will be a 109 series of NAPTR records. The format of a NAPTR Resource Record 110 can be found in Section 4. 112 Rule Insertion Procedure: 113 Rules are inserted by adding new records to the appropriate DNS 114 zone. If a Rule produces a Key that exists in a particular zone 115 then only the entity that has administrative control of that zone 116 can specify the Rule associated with that Key. 118 Collision Avoidance: 119 In the case where two Application may use this Database (which is 120 actually the case with the ENUM and URI Resolution Applications), 121 there is a chance of collision between rules where two NAPTR 122 records appear in the same DNS zone but they apply to more than 123 one Appliation. There are three ways to avoid collisions: 125 * create a new DNS zone in the zone which the administrator has 126 authority that contains only NAPTR records that are 127 appropriate for the application. E.g., all URI Resolution 128 records are put into urires.example.com and all ENUM records 129 are put into enum.example.com. In the case where this is not 130 possible due to lack of control over the upstream delegation 131 the second method is used. 133 * write the regular expression such that it contains enough of 134 the Application Unique string to disambiguate it from any 135 other. For example, the URI Resolution Application would be 136 able to use the scheme name on the left hand side to anchor 137 the regular expression match to that scheme. An ENUM specific 138 record in that same zone would be able to anchor the left hand 139 side of the match with the "+" character which is defined by 140 ENUM to be at the beginning of every Application Unique 141 String. This way a given Appliation Unique String can only 142 match one or the other record, not both. 144 * if two Application use different Flags or Services values then 145 a record from another Application will be ignored since it 146 doesn't apply to the Services/Flags in question. 148 4. NAPTR RR Format 150 4.1 Packet Format 152 The packet format of the NAPTR RR is given below. The DNS type code 153 for NAPTR is 35. 155 The packet format for the NAPTR record is as follows 156 1 1 1 1 1 1 157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 158 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 159 | ORDER | 160 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 161 | PREFERENCE | 162 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 163 / FLAGS / 164 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 165 / SERVICES / 166 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 167 / REGEXP / 168 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 169 / REPLACEMENT / 170 / / 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 173 and as used here are defined in 174 RFC1035[1]. 176 ORDER 177 A 16-bit unsigned integer specifying the order in which the NAPTR 178 records MUST be processed in order to accurately represent the 179 ordered list of Rules. The ordering is from lowest to highest. 180 If two records have the same order value then they are considered 181 to be the same rule and should be selected randomly unless the 182 Preference numbers are different which means the randomization is 183 weighted according to the ratio of the Preference values. 185 PREFERENCE 186 Although it is called "preference" in deference to DNS 187 terminology, this field is equivalent to the Priority value in 188 the DDDS Algorithm. It is a 16-bit unsigned integer that 189 specifies the order in which NAPTR records with equal Order 190 values SHOULD be processed, low numbers being processed before 191 high numbers. This is similar to the preference field in an MX 192 record, and is used so domain administrators can direct clients 193 towards more capable hosts or lighter weight protocols. A client 194 MAY look at records with higher preference values if it has a 195 good reason to do so such as not understanding some protocol or 196 service. 198 The important difference between Order and Preference is that 199 once a match is found the client MUST NOT consider records with a 200 different Order but they MAY process records with the same Order 201 but different Preferences. I.e. Preference is used to give weight 202 to rules that are considered the same from an authority 203 standpoint but not from a simple load balancing standpoint. 205 FLAGS 206 A containing flags to control aspects of the 207 rewriting and interpretation of the fields in the record. Flags 208 are single characters from the set [A-Z0-9]. The case of the 209 alphabetic characters is not significant. 211 It is up to the Application specifying how it is using this 212 Database to define the Flags in this field. It must define which 213 ones are terminal and which ones are not. 215 SERVICES 216 A that specifies the Service Parameters 217 applicable to this this delegation path. It is up to the 218 Application Specification to specify the values found in this 219 field. 221 REGEXP 222 A containing a substitution expression that is 223 applied to the original string held by the client in order to 224 construct the next domain name to lookup. See the DDDS Algorithm 225 specification for the syntax of this field. 227 As stated in the DDDS algorithm, The regular expressions MUST NOT 228 be used in a cumulative fashion, that is, they should only be 229 applied to the original string held by the client, never to the 230 domain name produced by a previous NAPTR rewrite. The latter is 231 tempting in some applications but experience has shown such use 232 to be extremely fault sensitive, very error prone, and extremely 233 difficult to debug. 235 REPLACEMENT 236 A which specifies the The next domain-name to query 237 for depending on the potential values found in the flags field. 238 This field is used when the regular expression is a simple 239 replacement operation. Any value in this field MUST be a fully 240 qualified domain-name. Unless and until permitted by future 241 standards action, name compression is not to be used for this 242 field. This field and the REGEXP field together make up the 243 Substitution Expression in the DDDS Algorithm. They are also 244 mutually exclusive. If a record is returned that has values for 245 both fields then it is considered to be in error and should be 246 ignored. 248 4.2 Master File Format 250 The master file format follows the standard rules in RFC-1035[1]. 251 Order and preference, being 16-bit unsigned integers, shall be an 252 integer between 0 and 65535. The Flags and Services and Regexp 253 fields are all quoted s. Since the Regexp field 254 can contain numerous backslashes and thus should be treated with 255 care. See Section 10 for how to correctly enter and escape the 256 regular expression. 258 5. Application Specifications 260 This DDDS Database is usable by any application that makes use of 261 the DDDS algorithm. In addition to the items required to specify a 262 DDDS Application, an application wishing to use this Database must 263 also define the following values: 265 o What DNS zone the Key that is produced by the First Well Known 266 Rule belongs to. Any application must ensure that its rules do 267 not collide with rules used by another application making use of 268 this Database. For example, the 'foo' application might have all 269 of its First Well Known Keys be found in the 'foo.net' zone. 271 o What the allowed values for the Services and Protocols fields are. 273 o What the expected output is of the terminal rewrite rule 275 6. Examples 277 6.1 URN Example 279 The NAPTR record was originally specified for use with the a Uniform 280 Resource Name Resolver Discovery System. This example details how a 281 particular URN would use the NAPTR record to find a resolver service 282 that can answer questions about the URN. See [12] for the definitive 283 specification for this Application. 285 Consider a URN namespace based on MIME Content-Ids (this is very 286 hypothetical so do not rely on this). The URN might look like this: 288 urn:cid:199606121851.1@bar.example.com 290 This Application's First Well Known Rule is to extract the 291 characters between the first and second colon. For this URN that 292 would be 'cid'. The Application also specifies that, in order to 293 build a Database-valid Key, the string 'urn.arpa' should be appended 294 to the result of the First Well Known Rule. The result is 295 'cid.urn.arpa'. 297 Next, the client queries the DNS for NAPTR records for the 298 domain-name 'cid.urn.arpa'. The result is a single record: 300 cid.urn.arpa. 301 ;; order pref flags service regexp replacement 302 IN NAPTR 100 10 "" "" "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . 304 Since there is only one record, ordering the responses is not a 305 problem. The replacement field is empty, so the pattern provided in 306 the regexp field is used . We apply that regexp to the entire URN to 307 see if it matches, which it does. The \2 part of the substitution 308 expression returns the string "example.com". Since the flags field 309 is empty, the lookup is not terminal and our next probe to DNS is 310 for more NAPTR records where the new domain is 'example.com'. 312 Note that the rule does not extract the full domain name from the 313 CID, instead it assumes the CID comes from a host and extracts its 314 domain. While all hosts, such as 'bar', could have their very own 315 NAPTR, maintaining those records for all the machines at a site 316 could be an intolerable burden. Wildcards are not appropriate here 317 since they only return results when there is no exactly matching 318 names already in the system. 320 The record returned from the query on "example.com" might look like: 322 example.com. 323 ;; order pref flags service regexp replacement 324 IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. 325 IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. 326 IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. 328 Continuing with the example, note that the values of the order and 329 preference fields are equal in all records, so the client is free to 330 pick any record. The Application defines the flag 'a' to mean a 331 terminal lookup and that the output of the rewrite will be a 332 domain-name for which an A record should be queried. Once the client 333 has done that, it has the following information: the host, its IP 334 address, the protocol, and the services available via that protocol. 335 Given these bits of information the client has enough to be able to 336 contact that server and ask it questions about the URN. 338 Recall that the regular expression used \2 to extract a domain name 339 from the CID, and \. for matching the literal '.' characters 340 separating the domain name components. Since '\' is the escape 341 character, literal occurances of a backslash must be escaped by 342 another backslash. For the case of the cid.urn.arpa record above, 343 the regular expression entered into the master file should be 344 "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code 345 actually receives the record, the pattern will have been converted 346 to "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i". 348 6.2 E164 Example 350 The ENUM Working Group in the IETF has specified a service that 351 allows a telephone number to be mapped to a URI. The Application 352 Unique String for the ENUM Application is the E.164 telephone number 353 with the dashes removed. The First Well Known Rule is to remove all 354 characters from the the telephone number and then use the entire 355 number as the first Key. For example, the phone number 356 "770-555-1212" represented as an E.164 number would be 357 "+1-770-555-1212". Converted to the Key it would be "17705551212". 359 The ENUM Application at present only uses this Database. It 360 specifies that, in order to convert the first Key into a form valid 361 for this Database, periods are inserted between each digit, the 362 entire Key is inverted and then "e164.arpa" is appended to the end. 363 The above telephone number would then read 364 "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to 365 retrieve Rewrite Rules as NAPTR records. 367 For this example telephone number we might get back the following 368 NAPTR records: 370 $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. 372 IN NAPTR 100 10 "u" "sip+N2R" "!^.*$!sip:information@foo.se!" . 373 IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:information@foo.se!" . 375 ENUM uses the same 'u' flag as the URI Resolution Application. This 376 flag states that the Rule is terminal and that the output is a URL 377 which contains the information needed to contact that telephone 378 service. ENUM also uses the same format for its Service Parameters. 379 These state that the available protocols used to access that 380 telephone's service are either the Session Initiation Protocol or 381 SMTP mail. 383 7. Advice for DNS Administrators 385 Beware of regular expressions. Not only are they difficult to get 386 correct on their own, but there is the previously mentioned 387 interaction with DNS. Any backslashes in a regexp must be entered 388 twice in a zone file in order to appear once in a query response. 389 More seriously, the need for double backslashes has probably not 390 been tested by all implementors of DNS servers. 392 In order to mitigate zone file problems, administrators should 393 encourage those writing rewrite rules to utilize the 'default 394 delimiter' feature of the regular expression. In the DDDS 395 specification the regular expression starts with the character that 396 is to be the delimiter. Hence if the first character of the regular 397 expression is an exclamation mark ('!') for example then the regular 398 expression can usually be written without any backslashes. 400 8. Notes 402 A client MUST process multiple NAPTR records in the order 403 specified by the "order" field, it MUST NOT simply use the first 404 record that provides a known Service Parameter combination. 406 When multiple RRs have the same "order" and all other criteria 407 being equal, the client should use the value of the preference 408 field to select the next NAPTR to consider. However, because it 409 will often be the case where preferred protocols or services 410 exist, clients may use this additional criteria to sort the 411 records. 413 If the lookup after a rewrite fails, clients are strongly 414 encouraged to report a failure, rather than backing up to pursue 415 other rewrite paths. 417 9. IANA Considerations 419 The values for the Services and Flags fields will be determined by 420 the Application that makes use of this DDDS Database. Those values 421 may require a registration mechanism and thus may need some IANA 422 resources. This specification by itself does not. 424 10. Security Considerations 426 The NAPTR record, like any other DNS record, can be signed and 427 validated according to the procedures specified in DNSSEC. 429 This Database makes identifiers from other namespaces subject to the 430 same attacks as normal domain names. Since they have not been easily 431 resolvable before, this may or may not be considered a problem. 433 Regular expressions should be checked for sanity, not blindly passed 434 to something like PERL since arbitrary code can be included and 435 subsequently processed. 437 References 439 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 440 Levels", RFC 2119, BCP 14, March 1997. 442 [2] Mockapetris, P.V., "Domain names - implementation and 443 specification", RFC 1035, STD 13, Nov 1987. 445 [3] Mockapetris, P.V., "Domain names - concepts and facilities", 446 RFC 1034, STD 13, Nov 1987. 448 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 449 specifying the location of services (DNS SRV)", RFC 2782, 450 February 2000. 452 [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 453 RFC 2234, November 1997. 455 [6] Daniel, R., "A Trivial Convention for using HTTP in URN 456 Resolution", RFC 2169, June 1997. 458 [7] IEEE, "IEEE Standard for Information Technology - Portable 459 Operating System Interface (POSIX) - Part 2: Shell and 460 Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. 462 [8] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 463 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 464 1998. 466 [9] Moats, R., "URN Syntax", RFC 2141, May 1997. 468 [10] Sollins, K., "Architectural Principles of Uniform Resource 469 Name Resolution", RFC 2276, January 1998. 471 [11] Mealling, M., "Dynamic Delegation Discovery System (DDDS)", 472 RFC ZZZZ, Internet-Draft draft-ietf-urn-ddds-00.txt, May 2000. 474 [12] Mealling, M., "URI Resolution using the Dynamic Delegation 475 Discovery System", RFC XXXX, Internet-Draft 476 draft-ietf-urn-uri-res-ddds-00.txt, July 2000. 478 [13] Mealling, M. and R. Daniel, "The Naming Authority Pointer 479 (NAPTR) DNS Resource Record", RFC 2915, August 2000. 481 [14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource 482 Identifiers using the Domain Name System", RFC 2168, June 1997. 484 [15] "Appendix A.2 of "The Unicode Standard, Version 2.0"", ISBN 485 0-201-48345-9, January 1996. 487 Author's Address 489 Michael Mealling 490 Verisign 491 505 Huntmar Park Drive 492 Herndon, VA 22070 493 US 495 Phone: +1 770 921-2251 496 EMail: michaelm@netsol.com 497 URI: http://www.verisign.com 499 Full Copyright Statement 501 Copyright (C) The Internet Society (2000). All Rights Reserved. 503 This document and translations of it may be copied and furnished to 504 others, and derivative works that comment on or otherwise explain it 505 or assist in its implmentation may be prepared, copied, published 506 and distributed, in whole or in part, without restriction of any 507 kind, provided that the above copyright notice and this paragraph 508 are included on all such copies and derivative works. However, this 509 document itself may not be modified in any way, such as by removing 510 the copyright notice or references to the Internet Society or other 511 Internet organizations, except as needed for the purpose of 512 developing Internet standards in which case the procedures for 513 copyrights defined in the Internet Standards process must be 514 followed, or as required to translate it into languages other than 515 English. 517 The limited permissions granted above are perpetual and will not be 518 revoked by the Internet Society or its successors or assigns. 520 This document and the information contained herein is provided on an 521 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 522 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 523 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 524 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 525 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 527 Acknowledgement 529 Funding for the RFC editor function is currently provided by the 530 Internet Society.