idnits 2.17.1 draft-boschi-export-perpktinfo-00.txt: -(59): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(61): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(62): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(63): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(64): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(65): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(66): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(67): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(68): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(70): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(71): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(72): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(73): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(74): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(75): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(76): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 526. ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 18 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 263: '...ion data records SHOULD be sent prior ...' 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 (June 2005) is 6862 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) == Missing Reference: 'IPFIX-PROTO' is mentioned on line 300, but not defined == Unused Reference: 'DuGG03' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'DuGr00' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'QuZC04' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'GrDM98' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'TPBC03' is defined on line 476, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Cla05' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cla04' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Use of IPFIX for Export of Per-Packet Information 3 Internet-Draft E. Boschi 4 Document: draft-boschi-export-perpktinfo-00.txt Fraunhofer FOKUS 5 / Hitachi Europe 6 Expires: December 2005 L. Mark 7 Fraunhofer FOKUS 9 June 2005 11 Use of IPFIX for Export of Per-Packet Information 12 draft-boschi-export-perpktinfo-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other than 31 as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 26, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Use of IPFIX for Export of Per-Packet Information 47 Abstract 49 This document describes the usage of the IP Flow Information 50 Export (IPFIX) protocol for the case of exporting and processing 51 per-packet information. 52 The main idea is to separate the export of the information about 53 packets and flows those packets belong to, using two different 54 records. The association between the records is kept using 55 unique Flow or Template Identifiers. 57 Table of Contents 59 1. Introduction�����������������������������������������2 60 2. Terminology������������������������������������������2 61 3. General Problem Statement����������������������������3 62 4. Export Per-Packet Information������������������������3 63 5. Using Scopes�����������������������������������������5 64 6. Flow ID Management�����������������������������������5 65 7. Example of Per-Packet Information Export�������������6 66 8. IPFIX for per-packet information export and PSAMP����7 67 9. Export and evaluation considerations�����������������7 68 10. IANA Consideration�����������������������������������7 69 11. Security Considerations������������������������������7 70 12. References�������������������������������������������8 71 12.1 Normative References���������������������������������8 72 12.2 Informative References�������������������������������8 73 13. Author's Addresses�����������������������������������8 74 14. Intellectual Property Statement����������������������8 75 15. Copyright Statement����������������������������������9 76 16. Disclaimer�������������������������������������������9 78 1. Introduction 80 In the scope of passive QoS Measurements, there is often the 81 need to exchange and export measurement data in a finer 82 granularity then per flows. One typical application is passive 83 One-Way-Delay measurement; this draft takes it as example when 84 demonstrating the need for information export on a per-packet 85 basis. 87 The IPFIX protocol however, has been designed to export flow 88 records. A possible approach to export packet records using 89 IPFIX could be exporting flow records containing information 90 about single packets. This method has been proposed by the PSAMP 91 working group in [Cla04]. Exporting flow related information 92 per-packet introduces a high degree of redundancy. This draft 93 shows how packet information and flow information can be 94 efficiently exported and related using IPFIX. 96 2. Terminology 98 Collecting Process 99 The collecting process receives records of flow or packet 100 information. The data is stored for later processing (by 101 the calculation process) 103 Exporting Process 104 The exporting processes send flow and packet records to the 105 collecting processes. The records are generated by the 106 measurement process. 108 Filtering 109 Filtering selects a subset of packets by applying 110 deterministic functions on parts of the packet content like 112 Use of IPFIX for Export of Per-Packet Information 114 header fields or parts of the payload. A filtering process 115 needs to process the packet (look at packet header and/or 116 payload) in order to make the selection decision. 118 Measurement Device 119 A measurement device has access to at least one observation 120 point. It is hosting at least one measurement process and 121 one export process. 123 Metering/Measurement Process 124 The measurement process generates records of packet and 125 flow information. Packets passing the observation point are 126 captured, time stamped, filtered and classified. The 127 measurement process calculates the packet Ids. 129 Passive One-Way-Delay Measurement 130 Abbreviated: POWD Measurement 132 3. General Problem Statement 134 In [Cla05] the IPFIX working group has defined a protocol to 135 transport measurement data containing flow information. 137 The main purpose of the protocol is to exchange information 138 about IP traffic flows. In this scope a flow is defined by a set 139 of key attributes (source/destination address, 140 source/destination port, Layer3 Protocol Type, TOS/DSCP byte, 141 interface of the flow exporting network element). As such, a 142 flow is a collection of packets that share a set of common 143 attributes. 145 However, for a number of metrics there is a need to export 146 per-packet data. 148 A single packet could be considered a special case of a flow and 149 thus, per-packet information could be exported using flow 150 records. Doing this though would have consequences on the 151 efficiency of the exporting procedure, as it would mean 152 additional overhead. Packets belonging to the same flow share 153 common attributes, i.e. source address, destination address, 154 etc. Exporting these attributes on a per-packet basis, each time 155 with a different packet ID, would be redundant information. 157 There are cases however, where it is desirable to keep flow 158 information along with the per-packet information, that is, when 159 analyzing packet characteristics while observing flows. This 160 document proposes a solution that reduces the overhead caused by 161 the flow properties while keeping a link to flow information. 163 The proposed method does not need any changes to the IPFIX 164 protocol. 166 4. Export Per-Packet Information 168 Figure 1 depicts three packets belonging to flow A and one 169 packet belonging to flow B, respectively. It shows export 170 records containing packet information plus flow information 171 (source and destination address). Undoubtedly, the flow 172 information introduces a huge amount of redundancy, as it is 173 repeated for every packet in every record. Minimizing the 174 redundancy is a common problem in relational data base design 175 and we apply here similar solutions to those proposed in that 176 area. 178 Use of IPFIX for Export of Per-Packet Information 180 In Figure 2 we separate flow from packet information. In order 181 to maintain the relation between Packet Properties and Flow 182 Properties we introduce indices (idxA and idxB) for the Flow 183 Properties that are unique for all Flow Property entries. The 184 purpose of the indices is to serve as "primary key" that 185 identifies rows of the Flow Properties. More details about these 186 indices will be given in section 5. The rows are then referenced 187 by the Packet Properties by using the appropriate value for the 188 flow identifier. The linkage of one packet and flow B (srcB, 189 dstB, idxB) is explicitly drawn. 191 One-packet flows 192 +------+------+------------+---------+ 193 | srcA | dstA | packet info| ... | 194 +------+------+------------+---------+ 195 | srcA | dstA | packet info| ... | 196 +------+------+------------+---------+ 197 | srcB | dstB | packet info| ... | 198 +------+------+------------+---------+ 199 | srcA | dstA | packet info| ... | 200 +------+------+------------+---------+ 202 Figure 1: Flow and packet information represented in one-packet 203 flows 205 Packet Properties 206 +-----+------------+---------+ 207 Flow Properties >idxA | packet info| ... | 208 +------+------+-----+ +-----+------------+---------+ 209 | srcA | dstA |idxA < >idxA | packet info| ... | 210 +------+------+-----+ +-----+------------+---------+ 211 | srcB | dstB |idxB <-------->idxB | packet info| ... | 212 +------+------+-----+ +-----+------------+---------+ 213 >idxB | packet info| ... | 214 +-----+------------+---------+ 216 Figure 2: Flow information and packet information 218 The IPFIX protocol is template based like NetFlow version 9. For 219 a complete description of features of IPFIX refer to [Cla05]. 220 Templates define the structure of data to be exported, 221 describing data fields together with their type and meaning. 222 IPFIX specifies two types of records to export data: data 223 records and option data records. These records are defined via 224 template records and option template records. To export per- 225 packet-information we define two different templates: an option 226 template for Flow Properties and a template for Packet 227 Properties. 229 Figure 3 shows the relation between template and data sets for 230 packet and flow properties. The Flow Properties option template 231 defines the attributes for a flow; e.g. IP source and 232 destination address and the flowID. The flowID is a unique 233 identifier for a flow; this field allows packet records to 234 reference flow attributes. Subsequent option data records of 235 this template define the actual flows. The reference could be 236 alternatively provided by the TemplateID, as explained in 237 Section 5. 239 The format for the information related to single packets is 240 defined in the Packet Properties template. This information is 241 packet specific and normally not shared between many packets. 243 Use of IPFIX for Export of Per-Packet Information 245 Otherwise one would rather consider the information as flow 246 related and therefore it needs not be exported in every record. 248 +---------------------+ +-------------------+ 249 | Option Template Set | | Template Set | 250 | | | | Description of 251 | Flow Properties | | Packet Properties | exported data 252 +----------+----------+ +----------+--------+ 253 ...........|............................|......................... 254 | | 255 +----------v----------+ +----------v--------+ Exported data 256 | Option Data Set | | Data Set | with references 257 | <------+ | by means of flow 258 | Flow Properties | | Packet Properties | or template 259 +---------------------+ +-------------------+ identifiers 261 Figure 3: Template FlowSet and Data FlowSet dependencies 263 The Flow Properties option data records SHOULD be sent prior to 264 the corresponding Packet Properties data records. 266 5. Using Scopes 268 Flow Properties are sent via IPFIX option records. IPFIX option 269 records contain one or more scope fields. The Flow Properties 270 record can contain the FlowID and/or the TemplateID as scope 271 fields. There are three options: 273 1) Use FlowID as scope 274 The flow properties are valid for all data records containing 275 that flowID. This solution limits the number of different 276 flows that can be exported at the same tame in the same 277 observation domain to 2**32 (using 32 bits flowIDs) 278 2) Use FlowID and TemplateID as scope 279 The flow properties are valid only for data records referring 280 to the template specified by the TemplateIDand containing 281 that flowID. This allows the export up to 2**32 flows per 282 template. The solution is to be chosen when the number of 283 flows to be exported is expected to be very high (and beyond 284 the limit posed by solution 1) 285 3) Use TemplateID as scope 286 The flow properties are valid for all data records of the 287 specified template. In this case flowIDs are not needed but 288 the exporting process requires a templateID per flow. In the 289 general case this solution is not scalable but can be 290 suitable for certain applications (e.g. flow aggregation). 292 6. Flow properties Management 294 Like template IDs the flow IDs have to be unique per observation 295 domain (source identifier in the IPFIX header). There are no 296 constraints regarding the order of the Flow ID allocation. When 297 limiting the scope to special templates, the flow IDs have to be 298 unique per observation domain and template. 300 The considerations made in [IPFIX-PROTO] with regard to template 301 management apply for flow properties as well (e.g. the regular 302 retransmission when using an unreliable transport protocol). 304 Use of IPFIX for Export of Per-Packet Information 306 7. Example of Per-Packet Information Export 308 To demonstrate how to use IPFIX efficiently to export per-packet 309 information, this section proposes how to use the IPFIX protocol 310 for exporting flow information and per-packet information (in 311 this case related to a long-lived flow) for OWD computation. 313 In order to acquire a One-Way path delay information, two 314 measurement points with synchronized clocks must exist, one at 315 each end of the path under examination. Both measurement points 316 will capture packets, assign them timestamps and generate an 317 identifier for a packet passing that point. Each measurement 318 point will export its measurement data to a collecting process 319 where the data are correlated based on the packet identifiers 320 and timestamps and then the delay is calculated as a difference 321 of two timestamps of a packet pair. 323 The templates that would be needed for exporting measurement 324 data of this kind are illustrated in Figure 4. 325 The upper part of the figure shows the option template 326 containing the information concerning flows using the FlowID as 327 scope. The lower part displays the template with the packet 328 properties. 330 For passive One-Way-Delay measurement, the Packet Properties 331 template consists of at least Timestamp and Packet ID. 332 Additionally, this template contains a flow identifier field. In 333 packet records, the value of this field will contain one of the 334 unique indices of the flow records exported before. 336 +-------------------+-------------------+-----------------------+.. 337 | flowID | sourceAddressV4 | destinationAddressV4 | 338 | | | | 339 | unsigned32/vendor | ipv4Address/ID 8 | ipv4Address/ID 12 | 340 +-------------------+-------------------+-----------------------+.. 342 ..+------------------+--------------------+---------------------+.. 343 | classOfServiceV4 | protocolIdentifier | transportSourcePort | 344 | | | | 345 | octet/ID 5 | octet/ID 4 | unsigned16/ID 7 | 346 ..+------------------+--------------------+---------------------+.. 348 ..+--------------------------+ 349 | transportDestinationPort | 350 | | 351 | unsigned16/ID 11 | 352 ..+--------------------------+ 353 FlowPropTemplate 354 =================================================================== 355 PacketPropTemplate 356 +-------------------+-------------------+-------------------+.. 357 | packetTimestamp | packetID | packetLength | 358 | | | | 359 | unsigned64/vendor | unsigned32/vendor | unsigned32/vendor | 360 +-------------------+-------------------+-------------------+.. 362 ..+-------------------+ 363 | flowID | 364 | | 365 | unsigned32/vendor | 366 ..+-------------------+ 368 Figure 4: Example Templates for Flow and Packet Properties 370 Use of IPFIX for Export of Per-Packet Information 372 The delay is derived by a calculation step: At the collection 373 point packet records of two measurement points are gathered and 374 correlated by means of the packet ID. The resulting delay data 375 records are exported in a similar manner as the packet data have 376 been. Especially, the linkage between delay data and flow 377 information is represented with the discussed flow identifier 378 fields. The OWD properties contain the Packet Pair ID (which is 379 the packet ID matching that of the two contributing packet 380 records), a timestamp (which is the timestamp of the packet 381 passing the reference monitor point) in order to reconstruct a 382 time series, the calculated delay value, and finally a flow 383 identifier. 385 8. IPFIX for per-packet information export and PSAMP 387 In [Cla04] the PSAMP working group proposes to use IPFIX to 388 export packet information from a PSAMP Exporting Process to a 389 PSAMP Collecting Process. Even though no new version of the 390 draft has been produced so far the solution seems to be accepted 391 from the group. 392 While IPFIX is well suited for the purpose due to the good match 393 between the IPFIX and PSAMP architectures and to the fact that 394 IPFIX satisfies PSAMP requirements, the described approach has a 395 high degree of redundancy. It proposes to treat packets as flows 396 and export per-packet information using flow records. 397 We propose to use the solution described in this draft to 398 efficiently export PSAMP packet information. 400 9. Export and evaluation considerations 402 The main advantage of this proposed method to export per-packet 403 information is the reduced amount of measurement data that has 404 to be transferred from the exporter to the collector. In 405 addition there is less storage capacity needed at the collector 406 side. 408 On the other hand there is some extra processing power needed on 409 the exporter side to manage flow information and to assign 410 packets to flows. The collector has to process records of two 411 templates instead of just one but has to read and write less 412 data. Additional effort is needed when post processing the 413 measurement data, because now the correlation of flow and packet 414 information is needed. 416 In the above example (see Figure 4) using IPFIX to export the 417 measurement data for each received packet 28 bytes have to be 418 transferred (sourceAddressV4=4, destinationAddressV4=4, 419 classOfServiceV4=1, protocolIdentifier=1, transportSourcePort=2, 420 transportDestionationPort=2, packetTimestamp=8, packetID=4, 421 packetLength=2). Disregarding the IPFIX protocol overhead a flow 422 of 1000 packets produces 28000 bytes of measurement data. Using 423 the proposed optimization each packet produces an export of only 424 16 bytes (packetTimestamp=8, packetID=4, packetLength=2, 425 flowID=2). The export of the flow information produces 16 bytes 426 (sourceAddressV4=4, destinationAddressV4=4, classOfServiceV4=1, 427 protocolIdentifier=1, transportSourcePort=2, 428 transportDestionationPort=2, flowID =2). For a flow of 1000 429 packet this sums up to 16016 bytes. This is a decrease of more 430 than 40 percent. 432 10. IANA Consideration 434 This document does not imply any IANA action. 436 11. Security Considerations 438 Use of IPFIX for Export of Per-Packet Information 440 For the proposed use of the IPFIX protocol for export of 441 per-packet information the security considerations as for the 442 IPFIX protocol apply. 444 12. References 446 12.1 Normative References 448 [Cla05] Benoit Claise: IPFIX Protocol Specification, 449 IETF draft work in progress 450 , June 2005 452 [Cla04] Benoit Claise: PSAMP Protocol Specification, 453 Internet Draft , 454 February 2004 456 12.2 Informative References 458 [DuGG03] Nick Duffield, et Al.: A Framework for Packet 459 Selection and reporting, Internet Draft 460 , January 2005 462 [DuGr00] Nick Duffield, Matthias Grossglauser: Trajectory 463 Sampling for Direct Traffic Observation, 464 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 465 August 28 - September 1, 2000 467 [QuZC04] J. Quittek, et Al.: Requirements for IP Flow 468 Information Export, RFC 3917, October 2004 470 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, 471 Jed MARTENS, John G. CLEARY: Nonintrusive and 472 Accurate Measurement of Unidirectional Delay and 473 Delay Variation on the Internet, INET'98, Geneva, 474 Switzerland, July 21-24, 1998 476 [TPBC03] T. Zseby, E. Boschi, R. Penno, N. Brownlee, B. 477 Claise: IPFIX Applicability, Internet Draft 478 , May 2005 480 13. Author's Addresses 482 Elisa Boschi 483 Fraunhofer Institute for Open Communication Systems 484 Kaiserin-Augusta-Allee 31 485 10589 Berlin 486 Germany 487 Phone: +49-30-34 63 7366 488 Fax: +49-30-34 53 8366 489 Email: boschi@fokus.fraunhofer.de 491 Lutz Mark 492 Fraunhofer Institute for Open Communication Systems 493 Kaiserin-Augusta-Allee 31 494 10589 Berlin 495 Germany 496 Phone: +49-30-34 63 7306 497 Fax: +49-30-34 53 8306 498 Email: mark@fokus.fraunhofer.de 500 14. Intellectual Property Statement 502 The IETF takes no position regarding the validity or scope of 503 any Intellectual Property Rights or other rights that might be 504 claimed to pertain to the implementation or use of the 506 Use of IPFIX for Export of Per-Packet Information 508 technology described in this document or the extent to which any 509 license under such rights might or might not be available; nor 510 does it represent that it has made any independent effort to 511 identify any such rights. Information on the procedures with 512 respect to rights in RFC documents can be found in BCP 78 and 513 BCP 79. 515 Copies of IPR disclosures made to the IETF Secretariat and any 516 assurances of licenses to be made available, or the result of an 517 attempt made to obtain a general license or permission for the 518 use of such proprietary rights by implementers or users of this 519 specification can be obtained from the IETF on-line IPR 520 repository at http://www.ietf.org/ipr. 522 The IETF invites any interested party to bring to its attention 523 any copyrights, patents or patent applications, or other 524 proprietary rights that may cover technology that may be 525 required to implement this standard. Please address the 526 information to the IETF at ietf-ipr@ietf.org. 528 15. Copyright Statement 530 Copyright (C) The Internet Society (2005). This document is 531 subject to the rights, licenses and restrictions contained in 532 BCP 78, and except as set forth therein, the authors retain all 533 their rights. 535 16. Disclaimer 537 This document and the information contained herein are provided 538 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 539 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 540 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 541 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 542 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 543 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 544 FOR A PARTICULAR PURPOSE.