Re: [codec] Guidelines for Proposed CODEC Working Group

["Christian Hoene" <[e-mail]>]

Hello,

here my somewhat late comments to draft-valin-codec-guidelines-02 or my somewhat early comments to draft-codec-guidelines-00.

...

>              Guidelines for Proposed CODEC Working Group

Please remove "Proposed"

...
>
>1.  Introduction
>
>   This document describes a suggested process for work at the IETF on
>   standardization of high-quality audio codecs that are optimized for
>   use in interactive Internet applications and that can be widely
>   implemented and easily distributed among application developers,
>   service operators, and end users. 

Please remove the following text as it is only about motivations:

> Although several such codecs have
>   been developed "in the wild" outside the IETF or any other standards
>   development organization (SDO), there are several reasons for
>   pursuing such work within the IETF:
>
>   o  The IETF has produced a large "stack" of protocols and formats
>      that (1) solve a wide variety of problems related to communication
>      over the Internet and (2) can be widely implemented and easily
>      distributed among application developers, service operators, and
>      end users (we say that technologies meeting the second condition
>      are "unencumbered", as further described under Section 5 of this
>      document).  However, feedback received from application developers
>      and service operators indicates that the lack of standardized,
>      high quality, unencumbered audio codecs has inhibited the
>      development and deployment of interoperable Internet audio
>      applications.
>
>   o  Specification of such codecs within the Internet Standards Process
>      would ensure more transparent, stringent, and trusted change
>      control than is currently available "in the wild".
>
>   o  In order to develop audio codecs that are optimized for use over
>      the Internet, it is important to gain input from the entire
>      Internet community and to incorporate cross-area review from the
>      full range of technical experts who work within the IETF,
>      including areas such as transport, routing, operations,
>      architecture, applications, and security.
>
>   o  The Internet Standards Process provides a transparent process for
>      the development of Internet technologies, in which any interested
>      member of the Internet community can participate.
>
>   o  The IETF's policies toward Intellectual Property Rights (IPR), as
>      codified in BCP 79 [IPR], facilitate (but do not guarantee) the
>      development of unencumbered audio codecs.
>
till here...

>   This document describes suggested processes for work on
>   standardization of unencumbered Internet audio codecs within the
>   Internet Standards Process, in particular as guidance to the proposed
>   Codec Working Group.  Nothing in this document shall be taken to
>   override official IETF policies and procedures as codified in BCP 9,
>   BCP 78, BCP 79, or any other approved document.  In case the
>
>
>
>Valin, et al.            Expires April 29, 2010                 [Page 4]
>
>
>Internet-Draft              Codec Guidelines                October 2009
>
>
>   suggestions in this document conflict with official policies and
>   procedures, the official policies and procedures shall rule.

Please add:
   "Beside the procedures, this document also name stakeholders, who are actively involved the process of codec development and who
are indirectly involved because their protocols and components interface with the codec."

Remove (it is outdated)
>
>   Although the authors of this document consider formation of a working
>   group to be the most productive path forward because of the
>   consensus-building mechanisms inherent to working groups, work could
>   also be pursued through independent submissions, to which the
>   procedural guidelines suggested here would apply.
>
>   Furthermore, although this document sometimes speaks of "codec" in
>   the singular in order to simplify the text, IETF participants could
>   develop more than one codec; any decisions about the number of codecs
>   to work on, and when to work on them, would be subject to normal
>   consensus processes within the IETF.

till here.

...

>
>2.  Development Process
>
>   The process outlined here is intended to maximize the transparency of
>   work on codecs within the IETF.  Such work might involve development
>   of one or more completely new codecs, adaptation of an existing codec
>   to meet the requirements specified in the accompanying requirements
>   document [REQS], or integration between two or more existing codecs
>   that results in an improved codec combining the best aspects of each
>   codec.  

Please change the last sentence to the following sentence to bring it inline with the charter,
 " Such work might involve development
   of one codec with one or more coding modes or the adaptation of an existing codec
   to meet the requirements specified in the accompanying requirements
   document [REQS], or integration between two or more existing codecs
   that results in an improved codec combining the best aspects of each
   codec."

> To enable such procedural transparency, the contributor of an
>   existing codec must be willing to cede change control to the IETF and
>   should have sufficient knowledge of the codec to assist in the work
>   of adapting it or applying some of its technology to the development
>   or improvemnet of other codecs.  Furthermore, contributors need to be
>   aware that any codec that results from work within the IETF is likely
>   to be different from any existing codec that was contributed to the
>   Internet Standards Process.
>
>   Work on codec development is expected to proceed as follows:
>
>   1.  One or more IETF participants will identify the requirements to
>       be met by Internet codecs, in the form of an Internet-Draft (a
>       start at this task is provided in [REQS]).

Please change to: "   1.  IETF participants will identify the requirements to
       be met by Internet codecs in the form of an Internet-Draft. The 
       working group chairs shall compile a common requirements document."

>   2.  Interested parties will actively solicit the contribution of
>       existing or proposed new codecs to the Internet Standards
>       Process.  Ideally these contributions will occur in the form of
>       Internet-Drafts to enable the widest community review, although
>       any contributions made in accordance with BCP 78 and BCP 79 will
>       be acceptable (e.g., via mailing list or a presentation during a
>       WG session).  If there is any IPR related to a contributed codec,
>       the contribution should be accompanied by an appropriate IPR
>       disclosure (IPR issues are described in more detail under
>       Section 5).
>
>   3.  As contributions are received and discussed within the working
>       group, the group will gain a clearer understanding of what is
>       achievable within the design space.  As a result, the authors of
>       the requirements document [REQS] should iteratively clarify and
>       improve their document to reflect the emerging working group
>       consensus. 

Please change to "As a result, the authors editors of
       the common requirements document [REQS] should iteratively clarify and
       improve their document to reflect the emerging working group
       consensus."

...
>
>3.  Evaluation, Testing, and Characterization
>
...
>   Characterization of the final codec must be based on the reference
>   implementation only (and not on any "private implementation").  This
>   can be performed by independent testing labs or, if this is not
>   possible, using the testing labs of the organizations that contribute
>   to the Internet Standards Process.  

Other STD had bad experience if the codec developers evaluate their codecs. Typical, the own codec is always is best. These opinions
are just human but procedures should be established to get an unbiased evaluation.

...
>
>4.  Requirements Conformance

General comment: This chapter contains already requirements but this is not the requirements document. It is better to move does to
the requirements document.
>
>   It is the responsibility of the working group to define criteria for
>   evaluating conformance, including but not limited to comparison tools
>   and test vectors.  The following text provides suggestions for
>   consideration by the working group.

...
>
>   Third, to reduce the risk of bias towards certain CPU/DSP
>   architectures, ideally the decoder specification would not have a
>   "bit-exact" definition.  The output of a decoder implementation
>   should only be "close enough" to the output of the reference decoder.
>   A comparison tool should be provided along with the codec to verify
>   objectively that the output of a decoder is likely to be perceptually
>   indistinguishable from that of the reference decoder.  However, to
>   simplify the testing procedure, an implementation may still wish to
>   produce an output that is bit-exact with the reference
>   implementation.  The packet loss concealment (PLC) algorithm need not
>   be normative. 

Again, this is a requirement (that I do not agree with). I will provide proper arguments for a standardized PLC, if the requirements
document is going to be discussed.

...
>
>5.  Intellectual Property
>
>   The codec should be "unencumbered".  At a high level, this means that
>   any party wishing to implement, deploy, or distribute the codec in
>   software, in hardware, or in a service can do so without requesting a
>   license, entering into a business agreement, paying licensing fees or
>   royalties, or otherwise adhering to special conditions or
>   restrictions stipulated by patent holder(s).

Please remove the following text because it describes the motivation not procedures.

>
>   Producing an unencumbered codec is important for the following
>   reasons:
>
>   o  The IETF already defines a comprehensive "stack" of unencumbered
>      protocols and formats for communication over the Internet.
>      However, there is a conspicuous gap in this stack for audio
>      codecs.  Although some unencumbered audio codecs have been
>      produced "in the wild", they have not been standardized within the
>      IETF or any other standards development organization, leading to
>      concerns about stability and change control that have hindered
>      adoption.
>
>   o  It is the experience of a wide variety of application developers
>      and service providers that encumbrances such as licensing and
>      royalties make it difficult to implement, deploy, and distribute
>      audio applications for use by the Internet community.
>
>   o  It is beneficial to have low-cost options whenever possible
>      because standalone voice services are being commoditized and
>      small, innovative development teams often cannot afford to pay
>      per-channel licensing fees and royalties.
>
>   o  Many market segments are moving away from selling hard-coded
>      hardware devices and toward freely distributing end-user software;
>      this is true of numerous large application providers and even
>      telcos themselves.
>
>   o  Compatibility with the licensing of typical open source
>      applications implies the need to avoid the kinds of encumbrances
>      listed above, including even the requirement to obtain a license
>      for implementation, deployment, or use (even if the license does
>      not require the payment of a fee).
>
>   Therefore, 

till here.

> The group shall prefer unencumbered technologies in a way
>   that is consistent with BCP 78 [TRUST] and BCP 79 [IPR], and shall
>   heed the preference stated in BCP 79: "In general, IETF working
>   groups prefer technologies with no known IPR claims or, for
>   technologies with claims against them, an offer of royalty-free
>   licensing."  Although this preference cannot guarantee that the group
>
>   will produce an unencumbered codec, the group shall attempt to adhere
>   to the spirit of BCP 79.  This preference does not explicitly rule
>   out the possibility of adapting encumbered technologies; such
>   decisions will be made in accordance with the rough consensus of the
>   group.
>
>   The following guidelines will help to maximize the odds that the
>   codec will be unencumbered:
>
>   1.  In accordance with BCP 79 [IPR], contributed codecs should
>       preferably use technologies with no known IPR claims or
>       technologies with an offer of royalty-free (RF) licensing.
>
>   2.  Given two, nearly equivalent technologies, the working group
>       should prefer technologies where any intellectual property rights
>       have expired.  In most jurisdictions, that means technologies
>       where the first publication was at least twenty years ago.  This
>       protects the work from both current IPR claims as well as
>       potential IPR the group is not aware of.
>
>   3.  Whenever possible, the working group should use technologies that
>       are perceived by the participants to be safer with regard to IPR
>       issues.

Please add "If known, the IETF draft shall reference to a document that has described the technology first or any other document
that is older than 20 years." 
Usually, IETF documents do not contain many citations. But, it will make the IPR search work easier if at least the draft will
contain all known references...

>
>   4.  If a technology under consideration is known to be covered by a
>       patent, the patent holder should be contacted and asked to
>       license the patent under acceptable RF terms (if the patent
>       holder is also a contributor, the license may have already been
>       specified in the IPR disclosure).
>
>   5.  In cases where no RF license can be obtained regarding a patent,
>       the group should consider alternative algorithms or methods, even
>       if they result in lower quality, higher complexity, or otherwise
>       less desirable characteristics (in most cases, the degradation
>       will likely be small once the best alternative has been
>       identified).
>
>   6.  In accordance with BCP 78 [TRUST], the source code for the
>       reference implementation should be made available under a BSD-
>       style license (or whatever license is defined as acceptable by
>       the IETF Trust when the Internet-Draft defining the reference
>       implementation is published).

Please add "7. Public participation shall be considered and strived for to help to search for encumbered technologies within the
IETF drafts."

>   IETF participants should be aware that, given the way patents work in
>   most countries, the resulting codecs can never be guaranteed to be
>   free of patent claims because some patents may not be known to the
>   contributors, some patent applications may not be disclosed at the
>   time the codec is developed, and only courts of law can determine the
>
>
>   validity and breadth of patent claims.  However, these observations
>   are no different within the Internet Standards Process than they are
>   for standardization of codecs within other SDOs (or development of
>   codecs outside the context of any SDO), and furthermore are no
>   different for codecs than for other technologies worked on within the
>   IETF.  In all these cases, the best approach is to minimize the risk
>   of unknowingly incurring encrumbrance on existing patents.  Despite
>   these precautions, participants need to understand that, practically
>   speaking, it is nearly impossible to guarantee that implementors will
>   not incur encumbrance on existing patents.
>

>
>6.  Relationship with Other SDOs
>
>   It is understood that other SDOs are also involved in the development
>   and standardization of audio codecs, including but not necessarily
>   limited to:
>
>   o  The Telecommunication Standardization Sector (ITU-T) of the
>      International Telecommunication Union (ITU), in particular Study
>      Group 16

Please change to "Group 12 and 16"

>
>   o  The Moving Picture Experts Group (MPEG)
>
>   o  The European Telecommunications Standards Institute (ETSI)
>
>   o  The 3rd Generation Partnership Project (3GPP)
>
>   o  The 3rd Generation Partnership Project 2 (3GPP2)
>

Please remove 
>   Clearly, there is no "natural monopoly" over codec work, since many
>   SDOs have defined codecs in parallel.  
till here.

> However, it is important to
>   ensure that such work does not constitute uncoordinated protocol
>   development, of the kind described in [UNCOORD] in the following
>   principle:
>
>      [T]he IAB considers an essential principle of the protocol
>      development process that only one SDO maintains design authority
>      for a given protocol, with that SDO having ultimate authority over
>      the allocation of protocol parameter code-points; defining the
>      intended semantics, interpretation, and actions associated with
>      those code-points.
>
>   The work envisioned by this guidelines document and the associated
>   requirements document [REQS] is not "uncoordinated" in the sense
>   described in the foregoing quote, for the following reasons:
>
>   o  Internet signalling technologies are designed to enable the
>      negotiation of any codecs that are supported in a particular
>      application (such signalling technologies include the Session
>      Initiation Protocol [SIP], Session Description Protocol [SDP], and
>      the Extensible Messaging and Presence Protocol [XMPP] extensions
>      for media negotiation as specified in [Jingle]).
>
>   o  Internet transport technologies such as the Real-time Transport
>      Protocol [RTP] (including secure transport as described in [SRTP])
>      are designed to support any codec for which RTP packetization
>      rules have been defined.
>
>   o  To the extent that codec work at the IETF differs from work at
>      other SDOs, it will focus on issues that are specific to the
>      Internet, including robustness to packet loss and other aspects of
>      packet transmission over the Internet.  Issues that are specific
>      to non-Internet transports (e.g., radio communication and circuit-
>      switched networks) are specifically out of scope.
>

Please remove the following text, because we cannot proof it's arguments.

>   Furthermore, as discussed under Section 5, the group will explicitly
>   attempt to develop a codec that is unencumbered or at least royalty-
>   free.  It is the understanding of the authors that non-technical
>   requirements related to IPR cannot be considered within the above-
>   mentioned SDOs until late in their standardization processes, if at
>   all.
>

Till here. The following text can be removed too because participation in the IETF is open to everybody.

>   Although there is already sufficient codec expertise available among
>   IETF participants to complete the envisioned work, additional
>   contributions are welcome within the framework of the Internet
>   Standards Process, in the following ways:
>
>   o  Individuals who are technical contributors to codec work within
>      other SDOs can participate directly in codec work within the IETF.
>
>   o  Other SDOs can contribute their expertise (e.g., codec
>      characterization and evaluation techniques) and thus facilitate
>      the testing of codecs produced by the IETF.
>
>   o  Any SDO can provide input to IETF work through liaison statements.

Till here. Please add instead

"In accordance with the liaison agreement in place, the working group
  will continue to coordinate with the ITU-T (Study group 16), with the
  intent of submitting the completed codec RFC for co-publication by the
  ITU-T if the ITU-T finds that appropriate. The working group will
  communicate a detailed description of the requirements and goals to
  other SDOs including the ITU-T, 3GPP, and MPEG to help determine if
  existing codecs meet the requirements and goals. Information about
  codecs being standardized will be available to other SDOs in the form of
  internet drafts and the working group welcomes technical feedback from
  other SDOs and experts from other organizations."

Remove "However,"
>
>   However, it is important to note that final responsibility for the
>   development process and the resulting codecs will remain with the
>   IETF as governed by BCP 9 [PROCESS].
>
>   Finally, there is precedent for the contribution of codecs developed
>   elsewhere to the ITU-T (e.g., AMR Wideband was standardized
>   originally within 3GPP).  This is a model to explore as the IETF
>   coordinates further with the ITU-T in accordance with the
>   collaboration guidelines defined in [COLLAB].
>
...

>
>10.  References
>
...
>
>   [REQS]     Valin, J., Borilin, S., Vos, K., Montgomery, C., and J.
>              Chen, "Codec Requirements",
>              draft-valin-codec-requirements-00 (work in progress),
>              September 2009.

Please update this reference to draft-codec-requirements-00

Just me first comments. I hope they help...

 Christian