idnits 2.17.1 draft-ietf-codec-guidelines-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2011) is 4672 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3979 (ref. 'IPR') (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 3356 (ref. 'COLLAB') (Obsoleted by RFC 6756) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group JM. Valin 3 Internet-Draft Octasic Inc. 4 Intended status: Informational S. Borilin 5 Expires: January 7, 2012 SPIRIT DSP 6 K. Vos 7 Skype Technologies S.A. 8 C. Montgomery 9 Xiph.Org Foundation 10 R. Chen 11 Broadcom Corporation 12 July 6, 2011 14 Guidelines for the Codec Development Within the IETF 15 draft-ietf-codec-guidelines-02 17 Abstract 19 This document provides general guidelines for work on developing and 20 specifying a codec within the IETF. These guidelines cover the 21 development process, evaluation, requirements conformance, and 22 intellectual property issues. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 7, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Development Process . . . . . . . . . . . . . . . . . . . . . 4 60 3. Evaluation, Testing, and Characterization . . . . . . . . . . 7 61 4. Specifying the Codec . . . . . . . . . . . . . . . . . . . . . 8 62 5. Intellectual Property . . . . . . . . . . . . . . . . . . . . 10 63 6. Relationship with Other SDOs . . . . . . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 69 10.2. Informative References . . . . . . . . . . . . . . . . . 18 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 72 1. Introduction 74 This document describes a suggested process for work at the IETF on 75 standardization of a codec that is optimized for use in interactive 76 Internet applications and that can be widely implemented and easily 77 distributed among application developers, service operators, and end 78 users. 80 2. Development Process 82 The process outlined here is intended to make the work on a codec 83 within the IETF transparent, predictable, and well organized. Such 84 work might involve development of a completely new codec, adaptation 85 of an existing codec to meet the requirements of the working group, 86 or integration between two or more existing codecs that results in an 87 improved codec combining the best aspects of each. To enable such 88 procedural transparency, the contributor of an existing codec must be 89 willing to cede change control to the IETF and should have sufficient 90 knowledge of the codec to assist in the work of adapting it or 91 applying some of its technology to the development or improvemnet of 92 other codecs. Furthermore, contributors need to be aware that any 93 codec that results from work within the IETF is likely to be 94 different from any existing codec that was contributed to the 95 Internet Standards Process. 97 Work on codec development is expected to proceed as follows: 99 1. IETF participants will identify the requirements to be met by an 100 Internet codec, in the form of an Internet-Draft. 102 2. Interested parties are encouraged to make contributions proposing 103 existing or new codecs, or elements thereof, to the codec WG as 104 long as these contributions are within the scope of the WG. 105 Ideally, these contributions should be in the form of Internet 106 Drafts, although other forms of contributions are also possible, 107 as discussed in [PROCESS]. 109 3. Given the importance of IPR to the activities of the working 110 group, any IPR disclosures must be made in a timely way. 111 Contributors are required, as described in [IPR], to disclose any 112 known IPR, both first and third party. Timely disclosures are 113 particularly important, since those disclosures may be material 114 to the decision process of the working group. 116 4. As contributions are received and discussed within the working 117 group, the group should gain a clearer understanding of what is 118 achievable within the design space. As a result, the authors of 119 the requirements document should iteratively clarify and improve 120 their document to reflect the emerging working group consensus. 121 This is likely to involve collaboration with IETF working groups 122 in other areas, such as collaboration with working groups in the 123 Transport area to identify important aspects of packet 124 transmission over the Internet and to understand the degree of 125 rate adaptation desirable, and with working groups in the RAI 126 area to ensure that information about and negotiation of the 127 codec can be easily represented at the signaling layer. In 128 parallel with this work, interested parties should evaluate the 129 contributions at a higher level to see which requirements might 130 be met by each codec. 132 5. Once a sufficient number of proposals has been received, the 133 interested parties will identify the strengths, weaknesses, and 134 innovative aspects of the contributed codecs. This step will 135 consider not only the codecs as a whole, but also key features of 136 the individual algorithms (predictors, quantizers, transforms, 137 etc.). 139 6. Interested parties are encouraged to collaborate together and 140 combine the best ideas from the various codec contributions into 141 a consolidated codec definition, representing the merging of some 142 of the contributions. Through this iterative process, the number 143 of proposals will reduce and consensus will generally form around 144 one of them. At that point, the working group should adopt that 145 document as a working group item, forming a baseline codec. 147 7. IETF participants should then attempt to iteratively add to or 148 improve each component of the baseline codec reference 149 implementation, where by "component" we mean individual 150 algorithms such as predictors, transforms, quantizers, and 151 entropy coders. The participants should proceed by trying new 152 designs, applying ideas from the contributed codecs, evaluating 153 "proof of concept" ideas, and using their expertise in codec 154 development to improve the baseline codec. Any aspect of the 155 baseline codec might be changed (even the fundamental principles 156 of the codec) or the participants might start over entirely by 157 scrapping the baseline codec and designing a completely new one. 158 The overriding goal shall be to design a codec that will meet the 159 requirements defined in the requirements document. Given the 160 IETF's open standards process, any interested party will be able 161 to contribute to this work, whether or not they submitted an 162 Internet-Draft for one of the contributed codecs. The codec 163 itself should be normatively specified with code in an Internet- 164 Draft. 166 8. In parallel with work on the codec reference implementation, 167 developers and other interested parties should perform evaluation 168 of the codec as described under Section 3, IETF participants 169 should define (within the AVT Working Group) the codec's payload 170 format for use with the Real-time Transport Protocol [RTP]. 171 Ideally, application developers should test the codec by 172 implementing it in code and deploying it in actual Internet 173 applications. Unfortunately, developers will frequently wait 174 until RFC or until a stable bitstream is guaranteed before 175 deployment. As such, this is a nice-to-have and not a 176 requirement for this process. Lab implementations are certainly 177 encouraged. 179 9. As the developed codec stabilizes and the group feels no more 180 changes are needed, the testing done to date is taken, along with 181 any additional testing required to give confidence that the codec 182 meets the requirements, and those test results form the final 183 characterization of the codec. The process of testing is 184 described under Section Section 3. 186 3. Evaluation, Testing, and Characterization 188 Lab evaluation of the codec being developed should happen throughout 189 the development process because it will help ensure that progress is 190 being made toward fulfillment of the requirements. There are many 191 ways in which continuous evaluation can be performed. For minor, 192 uncontroversial changes to the codec it should usually be sufficient 193 to use objective measurements (e.g., PESQ, PEAQ, and SegSNR) 194 validated by informal subjective evaluation. For more complex 195 changes (e.g., when psychoacoustic aspects are involved) or for 196 controversial issues, internal testing should be performed. An 197 example of internal testing would be to have individual participants 198 rate the decoded samples using one of the established testing 199 methodologies, such as ITU-R BS.1534 (MUSHRA). 201 Throughout the process, it will be important to make use of the 202 Internet community at large for real-world distributed testing. This 203 will enable many different people with different equipment and use 204 cases to test the codec and report any problems they experience. In 205 the same way, third-party developers will be encouraged to integrate 206 the codec into their software (with a warning about the bit-stream 207 not being final) and provide feedback on its performance in real- 208 world use cases. 210 Characterization of the final codec must be based on the reference 211 implementation only (and not on any "private implementation"). This 212 can be performed by independent testing labs or, if this is not 213 possible, using the testing labs of the organizations that contribute 214 to the Internet Standards Process. Packet loss robustness should be 215 evaluated using actual loss patterns collected from use over the 216 Internet, rather than theoretical models. The goals of the 217 characterization phase are to: 219 o ensure that the requirements have been fulfilled 221 o guide the IESG in its evaluation of the resulting work 223 o assist application developers in understanding whether the codec 224 is suitable for a particular application 226 The exact methodology for the characterization phase can be 227 determined the working group. Because the IETF does not have testing 228 resources of its own, it has to rely on the resources of its 229 participants. For this reason, even if the group agrees that a 230 particular test is important, if no one volunteers to do it, or if 231 volunteers do not complete it in a timely fashion, then that test 232 should be discarded. This ensures that only important tests be done, 233 and in particular those tests which are important to participants. 235 4. Specifying the Codec 237 Specifying a codec requires careful consideration around what is 238 required vs. what is left to the implementation. The following text 239 provides suggestions for consideration by the working group: 241 1. Any codec specified by the IETF must include source code for a 242 normative software implementation, documented in an Internet 243 Draft destined for standards track RFC. This implementation will 244 be used to verify conformance of an implementation. Although a 245 text description of the algorithm should be provided, its use 246 should be limited to helping the reader in understanding the 247 source code. Should the description contradict the source code, 248 the latter shall take precedence. For convenience, the source 249 code may be provided in compressed form, with base64 encoding. 251 2. Because of the size and complexity of most codecs, it is possible 252 that even after publishing the RFC, bugs will be found in the 253 reference implementation, or differences between the 254 implementation and the text description. An errata of the RFC 255 should be maintained, along with a public software repository 256 containing the current reference implementation. 258 3. It is the intention of the group to allow the greatest possible 259 choice of freedom in implementing the specification. 260 Accordingly, the number of binding RFC2119 keywords will be the 261 minimum that still allows interoperable implementations. In 262 practice this generally means that only the decoder needs to be 263 normative, so that the encoder can improve over time. This also 264 enables different trade-offs between quality and complexity. 266 4. To reduce the risk of bias towards certain CPU/DSP architectures, 267 ideally the decoder specification should not require "bit-exact" 268 conformance with the reference implementation. In that case, the 269 output of a decoder implementation should only be "close enough" 270 to the output of the reference decoder and a comparison tool 271 should be provided along with the codec to verify objectively 272 that the output of a decoder is likely to be perceptually 273 indistinguishable from that of the reference decoder. An 274 implementation may still wish to produce an output that is bit- 275 exact with the reference implementation to simplify the testing 276 procedure. 278 5. To ensure freedom of implementation, decoder-side only error 279 concealment does not need to be specified, although the reference 280 implementation should include the same PLC algorithm as used in 281 the testing phase. Is it up to the working group to decide 282 whether minimum requirements on PLC quality will be required for 283 compliance with the specification. Obviously, any information 284 signaled in the bitstream intended to aid PLC needs to be 285 specified. 287 6. An encoder implementation should not be required to make use of 288 all the "features" (tools) in the bit-stream definition. 289 However, the codec specification may require that an encoder 290 implementation be able to generate any possible bit-rate. Unless 291 a particular "profile" is defined in the specification, the 292 decoder must be able to decode all features of the bit-stream. 293 The decoder must also be able to handle any combination of bits, 294 even combinations that cannot be generated by the reference 295 encoder. It is recommended that the decoder specification shall 296 define how the decoder should react to "impossible" packets (e.g. 297 reject, consider as valid). However, an encoder must never 298 generate such packets that do not conform to the bit-stream 299 definition. 301 7. Compressed test vectors should be provided as a means to verify 302 conformance with the decoder specification. These test vectors 303 should be designed to exercise as much of the decoder code as 304 possible. 306 8. While the exact encoder will not be specified, it is recommended 307 to specify objective measurement targets for an encoder, below 308 which use of a particular encoder implementation is not 309 recommended. For example, one such specification could be: "the 310 use of an encoder whose PESQ MOS is better than 0.1 below the 311 reference encoder in the following conditions is not 312 recommended". 314 5. Intellectual Property 316 Producing an unencumbered codec is desirable for the following 317 reasons: 319 o It is the experience of a wide variety of application developers 320 and service providers that encumbrances such as licensing and 321 royalties make it difficult to implement, deploy, and distribute 322 multimedia applications for use by the Internet community. 324 o It is beneficial to have low-cost options whenever possible, 325 because innovation - the hallmark of the Internet - is hampered 326 when small development teams cannot deploy an application because 327 of usage-based licensing fees and royalties. 329 o Many market segments are moving away from selling hard-coded 330 hardware devices and toward freely distributing end-user software; 331 this is true of numerous large application providers and even 332 telcos themselves. 334 o Compatibility with the licensing of typical open source 335 applications implies the need to avoid encumbrances, including 336 even the requirement to obtain a license for implementation, 337 deployment, or use (even if the license does not require the 338 payment of a fee). 340 Therefore, a codec that can be widely implemented and easily 341 distributed among application developers, service operators, and end 342 users is preferred. Many existing codecs that might fulfill some or 343 most of the technical attributes listed above are encumbered in 344 various ways. For example, patent holders might require that those 345 wishing to implement the codec in software, deploy the codec in a 346 service, or distribute the codec in software or hardware need to 347 request a license, enter into a business agreement, pay licensing 348 fees or royalties, or adhere to other special conditions or 349 restrictions. Because such encumbrances have made it difficult to 350 widely implement and easily distribute high-quality codecs across the 351 entire Internet community, the working group prefers unencumbered 352 technologies in a way that is consistent with BCP 78 and BCP 79. In 353 particular, the working group shall heed the preference stated in BCP 354 79: "In general, IETF working groups prefer technologies with no 355 known IPR claims or, for technologies with claims against them, an 356 offer of royalty-free licensing." Although this preference cannot 357 guarantee that the working group will produce an unencumbered codec, 358 the working group shall follow BCP 79, and adhere to the spirit of 359 BCP 79. The working group cannot explicitly rule out the possibility 360 of adopting encumbered technologies; however, the working group will 361 try to avoid encumbered technologies that require royalties or other 362 encumbrances that would prevent such technologies from being easy to 363 redistribute and use. 365 When considering license terms for technologies with IRP claims 366 agains them, some members of the working group have expressed their 367 preference for license terms which: 369 o are available to all, worldwide, whether or not they are working 370 group participants 372 o extend to all essential claims owned or controlled by the licensor 374 o do not require payment of royalties, fees or other consideration 376 o do not require licensees to adhere to restrictions on usage 377 (though, licenses which apply only to implementation of the 378 standard are acceptable) 380 o do not otherwise impede the ability of the codec to be implemented 381 in open-source software projects 383 The following guidelines will help to maximize the odds that the 384 codec will be unencumbered: 386 1. In accordance with BCP 79 [IPR], contributed codecs should 387 preferably use technologies with no known IPR claims or 388 technologies with an offer of royalty-free (RF) licensing. 390 2. As described in BCP 79, the working group should use technologies 391 that are perceived by the participants to be safer with regard to 392 IPR issues. 394 3. Contributors must disclose IPR as specified in BCP 79. 396 4. In cases where no RF license can be obtained regarding a patent, 397 BCP 79 suggests that the working group consider alternative 398 algorithms or methods, even if they result in lower quality, 399 higher complexity, or otherwise less desirable characteristics. 401 5. In accordance with BCP 78 [TRUST], the source code for the 402 reference implementation must be made available under a BSD-style 403 license (or whatever license is defined as acceptable by the IETF 404 Trust when the Internet-Draft defining the reference 405 implementation is published). 407 Many IPR licenses specify that a license is granted only for 408 technologies which are adopted by the IETF as a standard. While 409 reasonable, this has the unintended side-effect of discouraging 410 implementation prior to RFC status. Real-world implementation is 411 beneficial for evaluation of the codec. As such, entities making IPR 412 license statements are encouraged to use wording which permits early 413 implementation and deployment. 415 IETF participants should be aware that, given the way patents work in 416 most countries, the resulting codec can never be guaranteed to be 417 free of patent claims because some patents may not be known to the 418 contributors, some patent applications may not be disclosed at the 419 time the codec is developed, and only courts of law can determine the 420 validity and breadth of patent claims. However, these observations 421 are no different within the Internet Standards Process than they are 422 for standardization of codecs within other SDOs (or development of 423 codecs outside the context of any SDO), and furthermore are no 424 different for codecs than for other technologies worked on within the 425 IETF. In all these cases, the best approach is to minimize the risk 426 of unknowingly incurring encumbrance on existing patents. Despite 427 these precautions, participants need to understand that, practically 428 speaking, it is nearly impossible to _guarantee_ that implementers 429 will not incur encumbrance on existing patents. 431 6. Relationship with Other SDOs 433 It is understood that other SDOs are also involved in the codec 434 development and standardization, including but not necessarily 435 limited to: 437 o The Telecommunication Standardization Sector (ITU-T) of the 438 International Telecommunication Union (ITU), in particular Study 439 Group 16 441 o The Moving Picture Experts Group (MPEG) of the International 442 Organization for Standardization and International 443 Electrotechnical Commission (ISO/IEC) 445 o The European Telecommunications Standards Institute (ETSI) 447 o The 3rd Generation Partnership Project (3GPP) 449 o The 3rd Generation Partnership Project 2 (3GPP2) 451 It is important to ensure that such work does not constitute 452 uncoordinated protocol development, of the kind described in 453 [UNCOORD] in the following principle: 455 [T]he IAB considers an essential principle of the protocol 456 development process that only one SDO maintains design authority 457 for a given protocol, with that SDO having ultimate authority over 458 the allocation of protocol parameter code-points; defining the 459 intended semantics, interpretation, and actions associated with 460 those code-points. 462 The work envisioned by this guidelines document is not uncoordinated 463 in the sense described in the foregoing quote, since the intention of 464 this process is that two possible outcomes might occur: 466 1. The IETF adopts an existing codec, and specifies that it is the 467 "anointed" IETF Internet codec. In such a case, codec ownership 468 lies entirely with the SDO which produced the codec, and not with 469 the IETF, OR 471 2. The IETF produces a new codec. Even if this codec uses concepts, 472 algorithms, codepoints, or even source code from a codec produced 473 by another SDO, the IETF codec is a specification unto itself and 474 under complete control of the IETF. Any changes or enhancements 475 made by the original SDO to the codecs whose components the IETF 476 used are not applicable to the IETF codec. Such changes would be 477 incorporated as a consequence of a revision or extension of the 478 IETF RFC. 480 Although there is already sufficient codec expertise available among 481 IETF participants to complete the envisioned work, additional 482 contributions are welcome within the framework of the Internet 483 Standards Process, in the following ways: 485 o Individuals who are technical contributors to codec work within 486 other SDOs can participate directly in codec work within the IETF. 488 o Other SDOs can contribute their expertise (e.g., codec 489 characterization and evaluation techniques) and thus facilitate 490 the testing of a codec produced by the IETF. 492 o Any SDO can provide input to IETF work through liaison statements. 494 However, it is important to note that final responsibility for the 495 development process and the resulting codec will remain with the IETF 496 as governed by BCP 9 [PROCESS]. 498 Finally, there is precedent for the contribution of codecs developed 499 elsewhere to the ITU-T (e.g., AMR Wideband was standardized 500 originally within 3GPP). This is a model to explore as the IETF 501 coordinates further with the ITU-T in accordance with the 502 collaboration guidelines defined in [COLLAB]. 504 7. Security Considerations 506 The procedural guidelines for codec development do not have security 507 considerations. However, the resulting codec needs to take 508 appropriate security considerations into account, for example as 509 outlined in [DOS] and [SECGUIDE]. 511 8. IANA Considerations 513 This document has no actions for IANA. 515 9. Acknowledgments 517 We would like to thank all the other people who contributed directly 518 or indirectly to this document, including Jason Fischl, Gregory 519 Maxwell, Alan Duric, Jonathan Christensen, Julian Spittka, Michael 520 Knappe, Timothy B. Terriberry, Christian Hoene, Stephan Wenger and 521 Henry Sinnreich. We also like to thank Cullen Jennings and Gregory 522 Lebovitz for their advice. Special thanks to Peter Saint-Andre, who 523 originally co-authored this document. 525 10. References 527 10.1. Normative References 529 [IPR] Bradner, S., "Intellectual Property Rights in IETF 530 Technology", BCP 79, RFC 3979, March 2005. 532 [PROCESS] Bradner, S., "The Internet Standards Process -- Revision 533 3", BCP 9, RFC 2026, October 1996. 535 [TRUST] Bradner, S. and J. Contreras, "Rights Contributors Provide 536 to the IETF Trust", BCP 78, RFC 5378, November 2008. 538 10.2. Informative References 540 [COLLAB] Fishman, G. and S. Bradner, "Internet Engineering Task 541 Force and International Telecommunication Union - 542 Telecommunications Standardization Sector Collaboration 543 Guidelines", RFC 3356, August 2002. 545 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 546 Service Considerations", RFC 4732, December 2006. 548 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 549 Jacobson, "RTP: A Transport Protocol for Real-Time 550 Applications", STD 64, RFC 3550, July 2003. 552 [SECGUIDE] 553 Rescorla, E. and B. Korver, "Guidelines for Writing RFC 554 Text on Security Considerations", BCP 72, RFC 3552, 555 July 2003. 557 [UNCOORD] Bryant, S. and M. Morrow, "Uncoordinated Protocol 558 Development Considered Harmful", RFC 5704, November 2009. 560 Authors' Addresses 562 Jean-Marc Valin 563 Octasic Inc. 564 4101, Molson Street 565 Montreal, Quebec 566 Canada 568 Email: jmvalin@jmvalin.ca 570 Slava Borilin 571 SPIRIT DSP 573 Email: borilin@spiritdsp.net 575 Koen Vos 576 Skype Technologies S.A. 577 Stadsgarden 6 578 Stockholm, 11645 579 Sweden 581 Email: koen.vos@skype.net 583 Christopher Montgomery 584 Xiph.Org Foundation 586 Email: xiphmont@xiph.org 588 Raymond (Juin-Hwey) Chen 589 Broadcom Corporation 591 Email: rchen@broadcom.com