idnits 2.17.1 draft-ietf-avt-rtp-ac3-07.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This payload format is defined for AC-3, as defined in the main part and Annex D of [ATSC]. It is not defined for E-AC-3, as defined in Annex E of [ATSC] and MUST not be used to carry E-AC-3. -- 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 6888 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ATSC' ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3267 (Obsoleted by RFC 4867) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) == Outdated reference: A later version (-05) exists of draft-freed-media-type-reg-04 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport B. Link 2 Internet-Draft T. Hager 3 Expires: December 2005 Dolby Laboratories 4 J. Flaks 5 Microsoft Corporation 6 June 2005 7 RTP Payload Format for AC-3 Audio 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware have 14 been or will be disclosed, and any of which he or she becomes aware 15 will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as 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/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes an RTP payload format for transporting AC-3 35 encoded audio data. AC-3 is a high quality, multichannel audio coding 36 system used in US HDTV, DVD, cable and satellite television and other 37 media. The RTP payload format as presented in this document includes 38 support for data fragmentation. 40 1. Introduction 42 AC-3 is a high quality audio codec designed to encode multiple channels 43 of audio into a low bit-rate format. AC-3 achieves its large 44 compression ratios via encoding a multiplicity of channels as a single 45 entity. Dolby Digital, which is a branded version of AC-3, encodes up 46 to 5.1 channels of audio. 48 AC-3 has been adopted as an audio compression scheme for many consumer 49 and professional applications. It is a mandatory audio codec for 50 DVD-video, Advanced Television Standards Committee (ATSC) digital 51 terrestrial television and Digital Living Network Alliance (DLNA) home 52 networking, as well as an optional multichannel audio format for 53 DVD-audio. 55 There is a need to stream AC-3 data over IP networks. RTP provides a 56 mechanism for stream synchronization and hence serves as the best 57 transport solution for AC-3, which is a codec primarily used in 58 audio-for-video applications. Applications for streaming AC-3 include 59 streaming movies from a home media server to a display, video on 60 demand, and multichannel Internet radio. 62 Section 2 gives a brief overview of the AC-3 algorithm. Section 3 63 specifies values for fields in the RTP header, while Section 4 64 specifies the AC-3 payload format, itself. Section 5 discusses MIME 65 types and SDP usage. Security considerations are covered in Section 6, 66 Congestion Control in Section 7, and IANA considerations in Section 8. 67 References are given in Sections 9 and 10. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 2. Overview of AC-3 75 AC-3 can deliver up to 5.1 channels of audio at data rates 76 approximately equal to half of one PCM channel [ATSC], [1994AC3], 77 [1996AC3]. The ".1" refers to a band-limited, optional, low-frequency 78 enhancement channel. AC-3 was designed for signals sampled at rates 79 of 32, 44.1, or 48 kHz. Data rates can vary between 32 kbps and 80 640 kbps, depending the number of channels and desired quality. 82 AC-3 exploits psychoacoustic phenomena that cause a significant 83 fraction of the information contained in a typical audio signal to be 84 inaudible. Substantial data reduction occurs via the removal of 85 inaudible information contained in an audio stream. Source coding 86 techniques are further used to reduce the data rate. 88 Like most perceptual coders, AC-3 operates in the frequency domain. A 89 512-point TDAC transform is taken with 50% overlap, providing 256 new 90 frequency samples. Frequency samples are then converted to exponents 91 and mantissas. Exponents are differentially encoded. Mantissas are 92 allocated a varying number of bits depending on the audibility of the 93 spectral components associated with them. Audibility is determined 94 via a masking curve. Bits for mantissas are allocated from a global 95 bit pool. 97 2.1 AC-3 Bit Stream 99 AC-3 bit streams are organized into synchronization frames. Each AC-3 100 frame contains a Sync Information (SI) field, a Bit Stream 101 Information (BSI) field, and 6 audio blocks (AB), each representing 102 256 PCM samples for each channel. The frame ends with an optional 103 auxiliary data field (AUX) and an error correction field (CRC). The 104 entire frame represents the time duration of 1536 PCM samples across 105 all coded channels [ATSC]. AC-3 encodes audio sampled at 32 kHz, 106 44.1 kHz, and 48 kHz. From Annex A, Part 2, of [ATSC], the time 107 duration of an AC-3 frame varies with the sampling rate as follows: 109 Sampling rate Frame duration 110 _____________________________________ 111 48 kHz 32 ms 112 44.1 kHz approx. 34.83 ms 113 32 kHz 48 ms 115 Figure 1 shows the AC-3 frame format. 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 |SI |BSI| AB0 | AB1 | AB2 | AB3 | AB4 | AB5 |AUX|CRC| 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Figure 1. AC-3 Frame Format 123 The Synchronization Information field contains information needed to 124 acquire and maintain codec synchronization. The Bit Stream 125 Information field contains parameters that describe the coded audio 126 service [ATSC]. Each audio block contains fields that 127 indicate the use of various coding tools: block switching, dither, 128 coupling, and exponent strategy. They also contain metadata, 129 optionally used to enhance the playback, such as dynamic range control. 130 Figure 2 shows the structure of an AC-3 audio block. Note that field 131 sizes vary depending on the coded data. 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Block |Dither |Dynamic |Coupling |Coupling |Exponent | 135 | Switch |Flags |Range Ctrl |Strategy |Coordinates |Strategy | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Exponents | Bit Allocation | Mantissas | 138 | | Parameters | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 2. AC-3 Audio Block Format 143 3. RTP Header Fields 145 Payload Type (PT): The assignment of an RTP payload type for this 146 packet format is outside the scope of this document; it is specified 147 by the RTP profile under which this payload format is used, or 148 signaled dynamically out-of-band (e.g., using SDP). 150 Marker (M) bit: The M bit is set to one to indicate that the RTP 151 packet payload contains at least one complete AC-3 frame or contains 152 the final fragment of an AC-3 frame. 154 Extension (X) bit: Defined by the RTP profile used. 156 Timestamp: A 32-bit word that corresponds to the sampling instant for 157 the first AC-3 frame in the RTP packet. Packets containing fragments 158 of the same frame MUST have the same time stamp. The timestamp of the 159 first RTP packet sent SHOULD be selected at random; thereafter it 160 increases linearly according to the number of samples included in each 161 frame (i.e. by 1536 for each frame). 163 4. RTP AC-3 Payload Format 165 This payload format is defined for AC-3, as defined in the main part 166 and Annex D of [ATSC]. It is not defined for E-AC-3, as defined in 167 Annex E of [ATSC] and MUST not be used to carry E-AC-3. 169 According to [RFC2736], RTP payload formats should contain an integral 170 number of application data units (ADUs). An ADU shall be equivalent 171 to an AC-3 frame. Each RTP payload MUST start with the two-byte 172 payload header followed by an integral number of complete AC-3 frames, 173 or a single fragment of an AC-3 frame. 175 If an AC-3 frame exceeds the MTU for a network, it SHOULD be 176 fragmented for transmission within an RTP packet. Section 4.2 177 provides guidelines for creating frame fragments. 179 4.1 Payload-Specific Header 181 There is a two-octet Payload Header at the beginning of each payload. 183 4.1.1 Payload Header 185 Each AC-3 RTP payload MUST begin with the following payload header. 186 Figure 3 shows the format of this header. 188 0 1 189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | MBZ | FT| NF | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 3. AC-3 RTP Payload Header 196 Must Be Zero (MBZ): Bits marked MBZ SHALL be set to the value zero and 197 SHALL be ignored by receivers. The bits are reserved for future 198 extensions. 200 Frame Type (FT): This two-bit field indicates the type of frame(s) 201 present in the payload. It takes the following values: 202 0 - One or more complete frames. 203 1 - Initial fragment of frame which includes the first 204 5/8ths of the frame. (See Section 4.2.) 205 2 - Initial fragment of frame, which does not include the 206 first 5/8ths of the frame. 207 3 - Fragment of frame other than initial fragment. (Note 208 that M bit in RTP header is set for final fragment.) 210 Number of frames/fragments(NF): An 8-bit field whose meaning depends 211 on the Frame Type (FT) in this payload. For complete frames (FT of 0), 212 it is used to indicate the number of AC-3 frames in the RTP payload. 213 For frame fragments (FT of 1, 2, or 3), it is used to indicate the 214 number fragments (and therefore packets) that make up the current 215 frame. NF MUST be identical for packets containing fragments of the 216 same frame. 218 Figure 4 shows the full AC-3 RTP payload format. 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+-+-+-+ 221 | Payload | Frame | Frame | | Frame | 222 | Header | (1) | (2) | | (n) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+-+-+-+ 225 Figure 4. Full AC-3 RTP payload 227 When receiving AC-3 payloads with FT = 0 and more than a single frame 228 (NF > 0), a receiver needs to use the "frmsizecod" field in the 229 synchronization information (syncinfo) block in each AC-3 frame to 230 determine the frame's length. That way a receiver can determine 231 the boundary of the next frame. Note that the frame length varies 232 from frame to frame in some circumstances. 234 4.2 Fragmentation of AC-3 Frames 236 The size of an AC-3 frame depends on the sample rate of the audio and 237 the data rate used by the encoder (which are indicated in the 238 "Synchronization Information" header in the AC-3 frame.) The size of 239 a frame, for a given sample rate and data rate, is specified in 240 Table 5.18 ("Frame Size Code Table") of [ATSC]. This table shows 241 that AC-3 frames range in size from a minimum of 128 bytes to a 242 maximum of 3840 bytes. If the size of an AC-3 frame exceeds the MTU 243 size, the frame SHOULD be fragmented at the RTP level. The 244 fragmentation MAY be performed at any byte boundary in the frame. RTP 245 packets containing fragments of the same AC-3 frame SHALL be sent in 246 consecutive order, from first to last fragment. This enables a 247 receiver to assemble the fragments in correct order. 249 When an AC-3 frame is fragmented, it MAY be fragmented such that at 250 least the first 5/8ths of the frame data is in the first fragment. 251 This provides greater resilience to packet loss. This initial 252 portion of any frame is guaranteed to contain the data necessary to 253 decode the first two blocks of the frame. Any frame fragments other 254 than those containing the first 5/8ths of frame data are only 255 decodable once the complete frame is received. The 5/8ths point of 256 the frame is defined in Table 7.34 ("5/8_frame Size Table") of 257 [ATSC]. 259 5. Types and Names 261 5.1 Media Type Registration 263 This registration uses the template defined in [DRAFT-FREED] and 264 follows RFC 3555 [RFC3555]. 266 Type name: audio 268 Subtype name: ac3 270 Required parameters: 271 rate: The RTP timestamp clock rate which is equal to the audio 272 sampling rate. Permitted rates are 32000, 44100, and 48000. 274 Optional parameters: 275 channels: From a sender, the maximum number of channels present 276 in the AC3 stream. From a receiver, the maximum number of 277 output channels the receiver will deliver. This MUST be a 278 number between 1 and 6. The LFE (".1") channel MUST be counted 279 as one channel. Note that the channel order used in AC-3 280 differs from the channel order scheme in [RFC3551]. The AC-3 281 channel order scheme can be found in Table 5.8 of [ATSC]. 283 ptime: See RFC 2327 [RFC2327]. 285 maxptime: See RFC 3267 [RFC3267]. 287 Encoding considerations: 288 This media type is framed (see section 4.8 in [DRAFT-FREED]) 289 and contains binary data. 291 Security considerations: 292 See Section 6 of this document. 294 Interoperability considerations: 295 none 297 Published specification: 298 This payload format specification and see [ATSC]. 300 Applications which use this media type: 301 Multichannel audio compression of audio and audio for video. 303 Additional Information: 304 Magic number(s): 305 The first two octets of an AC-3 frame are always the 306 synchronization word, which has the hex value 0x0B77. 308 Person & email address to contact for further information: 309 Brian Link 310 IETF AVT working group. 312 Intended Usage: 313 COMMON 315 Restrictions on usage: 316 This media type depends on RTP framing, and hence is only 317 defined for transfer via RTP [RFC3550]. Transport within other 318 framing protocols is not defined at this time. 320 Author/Change controller: 321 IETF Audio/Video Transport Working Group delegated from 322 the IESG. 324 5.2 SDP Usage 326 The information carried in the MIME media type specification has a 327 specific mapping to fields in the Session Description Protocol (SDP) 328 [RFC2327], which is commonly used to describe RTP sessions. When SDP 329 is used to specify sessions employing AC-3, the mapping is as follows: 331 o The Media type ("audio") goes in SDP "m=" as the media name. 333 o The Media subtype ("ac3") goes in SDP "a=rtpmap" 334 as the encoding name. 336 o The required parameter "rate" also goes in "a=rtpmap" as the 337 clock rate, optionally followed by the parameter "channel". 339 o The optional parameters "ptime" and "maxptime" go in the SDP 340 "a=ptime" and "a=maxptime" attributes, respectively. 342 An example of the SDP data for AC-3: 343 m=audio 49111 RTP/AVP 100 344 a=rtpmap:100 ac3/48000/6 346 Certain considerations are needed when SDP is used to perform 347 offer/answer exchanges [RFC3264]. The "rate" is a symmetric parameter 348 and the answer MUST use the same value or remove the payload type. 350 The "channels" parameter is declarative and indicates, for reconly or 351 sendrecv, the desired channel configuration to receive, and for 352 sendonly, the intended channel configuration to transmit. All 353 receivers are capable of receiving any of the defined channel 354 configurations and the parameter exchange might be used to help 355 optimize the transmission to the number of channels the receiver 356 requests. If the "channels" parameter is omitted, a default maximum 357 value of 6 is implied. "ptime" and "maxptime" are negotiated as 358 defined for "ptime" in RFC 3264 [RFC3264]. 360 6. Security Considerations 362 The payload format described in this document is subject to the 363 security considerations defined in RTP [RFC3550] and in any applicable 364 RTP profile (e.g. [RFC3551]). To protect the user's privacy and any 365 copyrighted material, confidentiality protection would have to be 366 applied. To also protect against modification by intermediate 367 entities and ensure the authenticity of the stream, integrity 368 protection and authentication would be required. Confidentiality, 369 integrity protection, and authentication have to be solved by a 370 mechanism external to this payload format, e.g., SRTP [RFC3711]. 372 The AC-3 format is designed so that the validity of data frames can 373 determined by decoders. The required decoder response to a malformed 374 frame is to discard the malformed data and conceal the errors in the 375 audio output until a valid frame is detected and decoded. This is 376 expected to prevent crashes and other abnormal decoder behavior in 377 response to errors or attacks. 379 7. Congestion Control 381 The general congestion control considerations for transporting RTP 382 data apply to AC-3 audio over RTP as well, see RTP [RFC3550], and any 383 applicable RTP profile (e.g., [RFC3551]). 385 AC-3 encoders may use a range of bit rates to encode audio data, so 386 it is possible to adapt network bandwidth by adjusting the encoder 387 bit rate in real time or by having multiple copies of content encoded 388 at different bit rates. Additionally, packing more frames in each RTP 389 payload can reduce the number of packets sent and hence the overhead 390 from IP/UDP/RTP headers, at the expense of increased delay and reduced 391 error robustness against packet losses. 393 8. IANA Considerations 395 Registration of a new media subtype for AC-3 is requested (see 396 Section 5.) 398 9. Normative References 400 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 401 Requirement Levels", RFC 2119, Internet Engineering Task Force, 402 March 1997. 404 [ATSC] U.S. Advanced Television Systems Committee (ATSC), "ATSC 405 Standard: Digital Audio Compression (AC-3), Revision B," Doc A/52B, 406 June 2005. 408 [RFC2327] Handley, M. and Jacobson, V., "SDP: Session Description 409 Protocol," RFC 2327, Internet Engineering Task Force, April 1998 411 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, 412 "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, 413 STD 64, July 2003. 415 [RFC3264] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model 416 with the Session Description Protocol (SDP)", RFC 3264, Internet 417 Engineering Task Force, June 2002. 419 [RFC3267] Sjoberg, J., et. al., "Real-Time Transport Protocol (RTP) 420 Payload Format and File Storage Format for the Adaptive Multi-Rate 421 (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", 422 RFC 3267, Internet Engineering Task Force, June 2002. 424 [RFC3555] Casner, S. and Hoschka, P., "MIME Type Registration of RTP 425 Payload Formats", RFC 3555, Internet Engineering Task Force, July 2003. 427 10. Informative References 429 [RFC2736] Handley, M. and Perkins, C., "Guidelines for Writers of RTP 430 Payload Format Specifications," RFC 2736, Internet Engineering Task 431 Force, December 1999. 433 [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio and 434 Video Conferences with Minimal Control", RFC 3551, Internet 435 Engineering Task Force, July 2003. 437 [1994AC3] Todd, C. et. al, "AC-3: Flexible Perceptual Coding for Audio 438 Transmission and Storage," Preprint 3796, Presented at the 96th 439 Convention of the Audio Engineering Society, May 1994. 441 [1996AC3] Fielder, L. et. al, "AC-2 and AC-3: Low-Complexity 442 Transform-Based Audio Coding," Collected Papers on Digital Audio 443 Bit-Rate Reduction, pp. 54-72, Audio Engineering Society, 444 September 1996. 446 [RFC3711] Baugher, M. et. al, "The Secure Real-time Transport Protocol 447 (SRTP)", RFC 3711, March 2004. 449 [DRAFT-FREED] Freed, N. and Klensin, J., "Media Type Specifications 450 and Registration Procedures", draft-freed-media-type-reg-04, 451 April 2005. 453 Authors' Addresses 455 Brian Link 456 Dolby Laboratories 457 100 Potrero Ave 458 San Francisco, CA 94103 460 Phone: +1 415 558 0200 461 Email: bdl@dolby.com 463 Todd Hager 464 Dolby Laboratories 465 100 Potrero Ave 466 San Francisco, CA 94103 468 Phone: +1 415 558 0136 469 Email: thh@dolby.com 470 Jason Flaks 471 Microsoft Corporation 472 1 Microsoft Way 473 Redmond, WA 98052 475 Phone: +1 425 722 2543 476 Email: jasonfl@microsoft.com 478 The IETF takes no position regarding the validity or scope of any 479 Intellectual Property Rights or other rights that might be claimed to 480 pertain to the implementation or use of the technology described in 481 this document or the extent to which any license under such rights 482 might or might not be available; nor does it represent that it has 483 made any independent effort to identify any such rights. Information 484 on the procedures with respect to rights in RFC documents can be 485 found in BCP 78 and BCP 79. 487 Copies of IPR disclosures made to the IETF Secretariat and any 488 assurances of licenses to be made available, or the result of an 489 attempt made to obtain a general license or permission for the use of 490 such proprietary rights by implementers or users of this 491 specification can be obtained from the IETF on-line IPR repository at 492 http://www.ietf.org/ipr. 494 The IETF invites any interested party to bring to its attention any 495 copyrights, patents or patent applications, or other proprietary 496 rights that may cover technology that may be required to implement 497 this standard. Please address the information to the IETF at 498 ietf-ipr@ietf.org. 500 Copyright (C) The Internet Society (2005). This document is subject 501 to the rights, licenses and restrictions contained in BCP 78, and 502 except as set forth therein, the authors retain all their rights. 504 This document and the information contained herein are provided on an 505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.