idnits 2.17.1 draft-rosenberg-mankin-newtrk-rfc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 494), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2004) is 7122 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) == Outdated reference: A later version (-06) exists of draft-allan-mpls-loadbal-05 -- Obsolete informational reference (is this intentional?): RFC 3932 (ref. '5') (Obsoleted by RFC 5742) -- Obsolete informational reference (is this intentional?): RFC 2705 (ref. '6') (Obsoleted by RFC 3435) -- Obsolete informational reference (is this intentional?): RFC 3525 (ref. '7') (Obsoleted by RFC 5125) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEWTRK J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: April 18, 2005 A. Mankin 4 October 18, 2004 6 What's In a Name: RFC 7 draft-rosenberg-mankin-newtrk-rfc-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 18, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Currently, the Request for Comments (RFC) moniker applies to all 41 documents that are published by the RFC editor. This includes 42 documents produced by IETF processes, such as IAB documents or 43 working group standards, on an equal footing with individual 44 contributions to the RFC editor. As a result, the term RFC does not 45 mean that a document has been produced by the IETF (though some 46 non-IETF RFCs strongly resemble IETF RFCs). This is at odds with the 47 understanding of the commons, which has come to view RFCs as the 48 output document series of the IETF. This document discusses the 49 importance of aligning fact with this common understanding, and 50 proposes that the name RFC be associated only with IETF documents. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Importance of Naming - Brand . . . . . . . . . . . . . . . . . 5 56 3. RFC as a Brand . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Should the IETF Care about Brand? . . . . . . . . . . . . . . 7 58 4.1 Decrease in Provider Demand for RFCs . . . . . . . . . . . 7 59 4.2 Decrease in Vendor Implementation of RFCs . . . . . . . . 7 60 4.3 Increase in Negative Perception of the IETF . . . . . . . 8 61 5. Why is this a problem now? . . . . . . . . . . . . . . . . . . 9 62 6. Defining RFC . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 66 10. Informative References . . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 68 Intellectual Property and Copyright Statements . . . . . . . . 15 70 1. Introduction 72 The Request For Comments (RFC) series of documents began over thirty 73 years ago with the publication of RFC 1 in 1969 at UCLA by Steve 74 Crocker. At the time, the Internet did not exist in its current 75 form. ARPANET was still under design, and the contract to build the 76 first Interface Message Processor (IMP) had just been awarded to Bolt 77 Baranek and Newman (BBN) [4]. 79 In the thirty five years since, a great deal has changed in the 80 technology and process that make up the Internet. Much of it is 81 documented in the long series of RFC documents, which at this time 82 number 3932 with the publication of RFC 3932 in October 2004 [5]. 84 The term RFC originally meant as the name implied - a request for 85 comments on a technical paper. According to the RFC editor web site, 86 an RFC series is a set of technical and organizational notes about 87 the Internet (originally the ARPANET), beginning in 1969. However, 88 many (but not all) of the documents published in the RFC series are 89 outputs of the IETF standards process [3]. Some are direct outputs 90 from the Internet Architecture Board (IAB). Some (the vast majority) 91 are developed by IETF working groups and passed through IESG, 92 according to the RFC 2026 process. A small number become IETF 93 standards through individual sponsorship in the same process. But, 94 some continue to be technical documents produced outside of the IETF 95 process, and sent directly to the RFC editor for publication. And 96 recently, a new category of document has become more common: 97 documents which began in IETF working groups, which look very much 98 like IETF standards work, but which are turned down from the IETF. 99 The archival records of this unfinished work or work which does not 100 gain consensus, becomes part of the RFC series as well. In the past, 101 all documents to be published as RFCs were reviewed by the IESG 102 whether or not they were products of the IETF. Now, however, the 103 IESG will only verify that the documents are not a standards end-run, 104 and if not, simply publish a statement on the document that the 105 publication has included no IETF review [5]. 107 Indeed, a surprising number of documents have been published as RFCs 108 outside of the IETF standards process. The precise number is 109 unknown, since one cannot tell from examination of the document 110 whether or not it was produced through that process. During the 111 2003/2004 period, the IESG considered 44 documents whose publication 112 was requested directly from the RFC editor. Of these, the IESG 113 recommended that 5 not be published. However, these recommendations 114 for "do-not-publish" are just recommendations. Ultimately, the RFC 115 editor has the right to independently assess whether to publish these 116 documents. In one instance, the RFC editor elected to publish the 117 document after some modifications, despite the IESG recommendations 118 otherwise. This document [2] is now in the RFC editor queue. 120 As a result of this, when a non-standards track document bears the 121 label "RFC", it is not possible to draw formal conclusions about that 122 document, beyond that it was published by the RFC editor. An example 123 can make this very clear. The Reliable Multicast Transport (RMT) 124 working group has published all of their documents initially as 125 Experimental RFCs, but with full working group, IETF and IESG review. 126 Their recent "standard" on a needed piece of multicast congestion 127 control is RFC 3738 [8]. A recent document on multicast and 128 differentiated service was submitted directly to the RFC Editor and 129 published as an Informational RFC, RFC 3754 [9]. This document did 130 not undergo a consensus process or community review. RMT states in 131 their text that they will evaluate RFC 3738 for standards track. RFC 132 3754 states that it is not the product of a working group. As a 133 result, we have two documents, one of which is experimental, one of 134 which is informational, both of which solve the same problem. One 135 was the product of the IETF, and the other was not. There is no way 136 to determine this by looking at the documents. Both documents are 137 RFCs, loud and clear. 139 This document discusses this issue, and in particular introduces the 140 notion of RFC as a "brand". It argues that this brand is a key asset 141 to the Internet community, and that it is essential that a clear and 142 unambiguous definition be given to the term RFC. It proposes that 143 this definition be tied to the key value propositions of the IETF - 144 technical quality and open standards. 146 2. Importance of Naming - Brand 148 It is of no suprise to IETF participants that the name given to 149 something is one of its most important attributes. In both the real 150 world and in computer science, a name is a reference. Its a way to 151 take something small and compact, and use it to help locate something 152 else. The name "sneaker" refers to a class of clothing worn on 153 peoples feet. The name "Allison Mankin" refers to a specific person. 154 The name "RFC 3261" refers to a specific document. 156 However, in the real world, a name also invokes emotion and meaning 157 in the mind of the person that sees the name. This meaning is built 158 up from the experiences that person has gathered over time about the 159 thing represented by the name. These experiences cause people to 160 make judgements when the name is invoked, and those judgements impact 161 behavior. 163 This simple fact is why corporations spend billions of dollars each 164 year to run ads and why the trademark system exists. It takes a long 165 time to establish a positive and consistent meaning around a name. 166 When this final does happen, it results in the creation of a brand. 167 Brands are not limited to retailers of consumer goods, they exist 168 everywhere. 170 Looking close to home, the IEEE 802 series of specifications 171 represents a brand. A large set of people in the engineering 172 community know that a specification starting with 802 refers to 173 ethernet, WiFi, and related technologies. The success of these 174 technologies has resulted in a positive association of the name 175 "802". People think of concepts such as "successful", "widely used" 176 and "important" when they see this name. Perhaps most importantly, 177 when a new 802 specification comes out, people associate these same 178 feelings with it, even though they would not have read or seen the 179 new spec. The brand carries value. 181 It is because people associate value with a brand, even before 182 understanding or even seeing, hearing or touching new things 183 associated with the brand, that brings incredible value to a 184 successful brand. Companies will fight long and hard to protect that 185 brand. Protection includes preventing others from using the brand, 186 and making sure that people continue to have a positive feeling when 187 the brand is invoked. 189 3. RFC as a Brand 191 The success of the Internet and of the specifications produced by the 192 IETF has also created a brand - "RFC". The RFC series are the 193 visible output of the IETF, and the place in which the core Internet 194 technologies - IP, TCP, email, web, and routing, to name a few - are 195 documented. As a result, whether it was intended or not, the name 196 "RFC" has become associated with "Internet Standards". One way to 197 quickly get the sense of this is to google for "RFC" and check what 198 the top sites say an RFC is. The following sites on the first page 199 of the google search results which provide a definition of RFC have 200 this to say: 201 www.rfc-editor.org: "The Requests for Comments (RFC) document series 202 is a set of technical and organizational notes about the Internet 203 (originally the ARPANET), beginning in 1969.". 204 www.rfc.net: "An RFC is a document describing the standards that make 205 the Internet work." 206 www.cse.ohio-state.edu/cs/Services/rfc/ " The Internet Request For 207 Comments (or RFC) documents are the written definitions of the 208 protocols and policies of the Internet." 209 www.rfc-ignorant.org: "...the RFCs, the building block "rules" of the 210 net." 212 The consistent statement, outside of the rfc-editor site itself, is 213 that an RFC is the documentation series of the standards that make 214 the Internet work. As a result, when a new document bears the 215 moniker RFC, it says something positive about the document to people, 216 even if they never read the document or even retrieve it. 218 4. Should the IETF Care about Brand? 220 The natural question to ask next is whether the IETF, and more 221 broadly, the Internet community, should care that the term RFC has 222 become a brand, and has come to mean "Internet Standard". The 223 easiest way to explore this question is to examine the implications 224 of this brand being eliminated. What would happen if, tomorrow, we 225 could change people's perceptions? What if people thought an RFC was 226 just a document, no different than the output of an academic 227 conference, some of which were produced by IETF, and some of which 228 represented an Internet standard? That is, let us assume that IETF is 229 still producing quality specifications, but people no longer 230 associated an RFC in any strong way with the IETF. 232 The implications are hard to predict, of course, in no small part 233 because much else would need to be broken for this fact to be true. 234 However, a few points can be made. 236 4.1 Decrease in Provider Demand for RFCs 238 When service providers look to build out a network, they often create 239 a Request for Product (RFP) that asks vendors whether or not they can 240 provide an enumerated set of capabilities. It is not uncommon 241 practice for providers to ask for all RFCs in a particular area, 242 without even having reviewed the content of the RFC in any great 243 detail to see if it solves real needs. That doesn't mean that 244 vendors go off and implement these specifications, or that provides 245 run and deploy them. However, it creates the seed for a converation 246 between vendors and providers, as the technology is discussed and 247 evaluated to assess whether or not it solves problems. In other 248 words, the mere fact that a technology is an RFC gives it special 249 consideration by service providers. Service providers don't usually 250 ask for technologies described in proceedings of academic conferences 251 or journals; they ask for documents produced by standards bodies, and 252 RFCs are included. 254 If RFCs lost their brand, service providers would not ask for them in 255 advance of detailed examination, and their consideration would, in 256 fact, be equal to any other series of documents not produced by a 257 standards organization - virtually nil. The bar would be raised much 258 higher for such a document to be considered, and as such, more good 259 work would go unnoticed, reducing overall demand for IETF 260 specifications. 262 4.2 Decrease in Vendor Implementation of RFCs 264 A natural consequence of the previous result is that vendors will 265 implement fewer IETF technologies, since they are ultimately driven 266 by provider demand. 268 4.3 Increase in Negative Perception of the IETF 270 If the RFC brand is no longer limited to Internet standards, but 271 rather, refers to almost any document produced about Internet 272 technologies, there will undoubtedly be good documents and bad 273 documents. Unfortunately, the name alone is insufficient to 274 differentiate documents that belong to IETF, versus ones that do not. 275 One would hope that everyone who reads or uses an RFC would cleanly 276 delineate in their minds and in their communications, RFCs that were 277 products of IETF and those which were not. However, human nature is 278 not that way. The nature of brand is that perception and value are 279 tied to the brand itself, even without understanding anything about 280 the specific products that make up the brand. 282 Thus, if RFC's were no longer viewed in a positive light, even if 283 this decline were do entirely to non-IETF documents, the perception 284 would be that IETF documents have also declined in quality. Worse 285 yet, once a brand loses its positive perception by the community, it 286 is almost impossible to recover. 288 Negative perception of the IETF has direct implications on IETF 289 attendance, finances, and the well-being of the organization overall. 291 Clearly, this argument is predicated on the fact that non-IETF RFCs 292 would be of lower quality than IETF produced RFCs. There are many 293 poor documents produced by IETF, and high quality ones produced 294 outside of the IETF process. Thus, the disassociation of RFC with 295 IETF does not, in and of itself imply a loss of quality. However, it 296 does imply that the quality of those documents resides outside of 297 IETF process and control. The purpose of this argument is to pose a 298 thought experiment - what would happen *if* this were to occur - in 299 order to demonstrate the importance of maintaining RFC as a brand. 301 5. Why is this a problem now? 303 The disconnect between the perception of an RFC and its actual 304 meaning is not new. This fact has existed for as long as the 305 industry perceived RFCs to just be the product of the IETF standards 306 process - perhaps the last 5-10 years. Clearly, during this period, 307 none of the aforementioned problems have occurred. Thus, is there a 308 real problem here? 310 This is an important question to address. The simplest answer is 311 that the disconnect leads to the possibility of the aforementioned 312 problems, not their certainty by any stretch of the imagination. As 313 such, just because we have not yet seen an incident that has tainted 314 the RFC brand, doesn't mean we won't in the future. It's like 315 wearing a seatbelt. If you don't, it doesn't mean you'll get into in 316 accident. However, wearing one protects you in case you do. 318 That said, the problem has become more pressing with the publication 319 of RFC 3932. With this change, IESG and IETF review no longer take 320 place for documents sent directly to the RFC editor, beyond a 321 determination of whether the specification is an end run around 322 standards. Previously, nearly 10% of the documents sent to RFC 323 editor for publication using this route were blocked by IESG and IETF 324 concerns in 2003 and 2004. Now, these documents will proceed towards 325 publication, subject to the standards and policies of the RFC editor. 326 Extending the analogy in the previous paragraph, we are now driving 327 the car much faster, and that means you really want to think about 328 that seatbelt. 330 Furthermore, the IETF and the Internet continues to mature. In 331 particular, it is now entering an era of increased government 332 attention. In an environment where the output of the IETF has the 333 interest and scrutiny of governments across the world, the 334 consequences of this problem become more dire. 336 Finally, although there haven't been any sizeable problems as a 337 result of this issue, there have been problems. One in particular is 338 the existence of both the Media Gateway Control Protocol (MGCP) [6] 339 and the Gateway Control Protocol version 1.0 (MEGACO) [7] as RFCs. 340 The former was an industry specification that was published as an 341 RFC, and the latter is the output of an IETF working group meant to 342 standardize a solution for the problem at hand. MGCP is arguably 343 more widely used and deployed than MEGACO. However, vendors have 344 complained about needing to implement both (both are requested by 345 service providers). 347 6. Defining RFC 349 The what-if scenarios in the previous section make it clear that it 350 is important to the Internet community to protect the value of RFC as 351 a brand. 353 However, there is currently a disconnect in the perception about what 354 an RFC is ("an Internet Standard") and what it actually is ("a series 355 of documents on Internet technologies"). One of the most important 356 ways a brand is maintained is through "authenticity" - make sure that 357 perception matches reality. As a result, it is important that 358 whatever the brand the community wishes RFC to have, should match 359 with what an RFC is. 361 It is our proposition that the value of an RFC to the industry is 362 tied to its perception as an "Internet standard", and that the name 363 RFC should only be granted to documents which match that criteria. 364 To be more specific, we would propose that there are two 365 characteristics of the IETF process that make it unique and impart 366 value: 367 Openness: The IETF process is open. Anyone can participate, and 368 small companies can have an influence over large ones when their 369 technology has merit. 370 Technical Quality: Technical quality of the documents is of great 371 concern to IETF. The IETF performs a review for technical 372 quality, and the IETF is striving to improve its ability to review 373 documents as it scales up [1]. 375 The IETF standards process, described in Section 6.1 of RFC 2026 [3] 376 defines the process for approval of documents. This process provides 377 the openness and technical review that are the key qualities of an 378 Internet standard. Although this process is described as applicable 379 to documents on the standards track (proposed standard, draft 380 standard and standard), it is currently used for nearly all documents 381 produced by the IETF. 383 7. Recommendation 385 Our proposal is that the term "RFC" only be given to documents which 386 are produced as part of the process described in Section 6.1 of RFC 387 2026. This includes working group documents and documents developed 388 outside of a working group. It includes experimental and 389 informational documents, in addition to standards track. All of 390 these documents are still published through the Internet standards 391 process, providing review, comment, an open process and a structure 392 for appeals. Documents published by the RFC editor, but did not go 393 through this process, should be given a different title and be part 394 of a different document series. These documents are still important 395 and still deserve publication. However, the name they are given 396 should be different. 398 8. Security Considerations 400 One of the benefits of the technical review that IETF provides is the 401 emphasis on security. If documents produced outside of the IETF, and 402 published as RFCs, do not have adequate security review, and those 403 documents see implementation, it could reduce the overall security of 404 the Internet. 406 9. Acknowledgements 408 The authors would like to thank Eric Rescorla for his comments. 410 10 Informative References 412 [1] Partain, D., "An Experiment in Early Cross-Area Review for the 413 IETF", draft-ietf-icar-experiment-early-review-00 (work in 414 progress), July 2004. 416 [2] Allan, D., "Guidelines for MPLS Load Balancing", 417 draft-allan-mpls-loadbal-05 (work in progress), October 2003. 419 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 420 9, RFC 2026, October 1996. 422 [4] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, J. and 423 C. Anderson, "30 Years of RFCs", RFC 2555, April 1999. 425 [5] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", 426 BCP 92, RFC 3932, October 2004. 428 [6] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, 429 "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, 430 October 1999. 432 [7] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, "Gateway 433 Control Protocol Version 1", RFC 3525, June 2003. 435 [8] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control 436 (WEBRC) Building Block", RFC 3738, April 2004. 438 [9] Bless, R. and K. Wehrle, "IP Multicast in Differentiated 439 Services (DS) Networks", RFC 3754, April 2004. 441 Authors' Addresses 443 Jonathan Rosenberg 444 Cisco Systems 445 600 Lanidex Plaza 446 Parsippany, NJ 07054 447 US 449 Phone: +1 973 952-5000 450 EMail: jdrosen@dynamicsoft.com 451 URI: http://www.jdrosen.net 452 Allison Mankin 454 EMail: mankin@psg.com 456 Intellectual Property Statement 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at 478 ietf-ipr@ietf.org. 480 Disclaimer of Validity 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 485 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 486 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 487 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 Copyright Statement 492 Copyright (C) The Internet Society (2004). This document is subject 493 to the rights, licenses and restrictions contained in BCP 78, and 494 except as set forth therein, the authors retain all their rights. 496 Acknowledgment 498 Funding for the RFC Editor function is currently provided by the 499 Internet Society.