Subject: [video-codec] Charter update

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 08 Jan 2013 23:14:08 -0800

Rob's paragraph looked basically fine, so I have incorporated it below 
(diff attached).

Basil, while I am sympathetic to your concern, the last time (when 
forming the codec WG), there was a great deal of argument against giving 
preference to the open source "business model" over other business 
models. The current phrasing represents the compromise that was reached 
at that time. This is an argument that I do not greatly wish to re-open. 
As with Opus, I don't think this will be a problem in practice.

Christian, I personally tend to think, unlike the authors of that paper, 
that P2P transfers are the _most_ expensive way to do distribution. They 
move all the traffic out to the last mile, onto networks that were not 
designed for it, and where it is very costly. We at Xiph.Org 
experimented with P2P Streaming as far back as 2004 (see 
https://wiki.xiph.org/IceShare), but there was never a great deal of 
interest in it, and the project has been basically dead for the past 5 
years or more.

I think we are in pretty good shape now, and I would like to get this 
submitted to the IESG relatively soon. Please send any final comments 
(on the _charter_) to the list by 17:00 PST, January 15th.

Full text of the updated charter, for reference:

Problem Statement

According to reports from developers of Internet video applications and 
operators of Internet video services, there is no standardized, 
high-quality video codec that meets all of the following three conditions:

1. Is optimized for use in interactive Internet applications.

2. Is published by a recognized standards development organization (SDO) 
and therefore subject to clear change control and IPR disclosure rules.

3. Can be widely implemented and easily distributed among application 
developers, service operators, and end users.

There exist codecs that provide high quality encoding of video 
information, but that are not optimized for the actual conditions of the 
public, consumer-level, best-effort Internet. Such optimizations might 
include fast and flexible congestion control, such as the ability to 
change resolution without sending a keyframe; a simple means of handling 
packet loss in the face of reference frame re-ordering; the ability to 
join broadcast streams without waiting for a keyframe; special coding 
tools for screen captures to support remote services and desktop 
sharing; and many more. According to reports, this mismatch between 
design and deployment has hindered performance and interoperability of 
such codecs in Internet applications.

There exist codecs that can be widely implemented, but were not 
developed under the IPR rules of any SDO; according to reports, the lack 
of clarity in their IPR status has hindered adoption of such codecs in 
Internet applications.

There exist codecs that are standardized, but that cannot be widely 
implemented and easily distributed; according to reports, the presence 
of various usage restrictions (e.g., in the form of requirements to pay 
royalty fees, obtain a license, enter into a business agreement, or meet 
other special conditions imposed by a patent holder) has hindered 
adoption of such codecs in Internet applications.

According to application developers and service operators, a video codec 
that meets all three of these conditions would: (1) enable protocol 
designers to more easily specify a mandatory-to-implement codec in their 
protocols and thus improve interoperability; (2) enable developers to 
more easily build innovative applications for the Internet; (3) enable 
service operators to more easily deploy affordable, high-quality video 
services on the Internet; and (4) enable end users of Internet 
applications and services to enjoy an improved user experience.

Objectives

The goal of this working group is to ensure the existence of a single 
high-quality video codec that can be widely implemented and easily 
distributed among application developers, service operators, and end 
users. At present it appears that ensuring the existence of such a codec 
will require a development effort within the working group.

The core technical considerations for such a codec include, but are not 
necessarily limited to, the following:

1. Designing for use in interactive applications (examples include, but 
are not limited to, point-to-point video calls, multi-party video 
conferencing, telepresence, teleoperation, and in-game video chat).

2. Addressing the real transport conditions of the Internet, such as the 
flexibility to rapidly respond to changing bandwidth availability and 
loss rates, or as otherwise identified and prioritized by the working group.

3. Ensuring interoperability and clean integration with the Real-time 
Transport Protocol (RTP), including secure transport via SRTP.

4. Ensuring interoperability with Internet signaling technologies such 
as Session Initiation Protocol (SIP), Session Description Protocol 
(SDP), and Extensible Messaging and Presence Protocol (XMPP). However, 
the result should not depend on the details of any particular signaling 
technology.

5. Ensuring suitability for use in Internet applications and Web APIs, 
such as the HTML5 <video> tag, live streaming (e.g., via icecast), 
adaptive streaming (e.g., Dynamic Adaptive Streaming over HTTP (DASH), 
HTTP Live Streaming (HLS), etc.), the MediaSource API, the WebRTC APIs, 
proposed web recording APIs, and so on. However, the result should not 
depend on the details of any particular API.

Optimizing for very low bit rates (typically below 64 kbps) is out of 
scope because such work might necessitate specialized optimizations.

In addition to the technical objectives, there is one process goal, which is

6. Ensuring the work is done under the IPR rules of the IETF.

Although a codec produced by this working group or another standards 
organization might be used as a mandatory-to-implement technology by 
designers of particular Internet protocols, it is explicitly not a goal 
of the working group to produce a codec that will be mandated for use 
across the entire IETF or Internet community nor would their be any 
expectation that this would be the only mandatory-to-implement codec.

Based on the working group's analysis of the design space, the working 
group might determine that it needs to produce a codec with multiple 
modes of operation. However, it is not the goal of working group to 
produce more than one codec.

In completing its work, the working group should collaborate with other 
IETF working groups to complete particular tasks. These might include, 
but would not be limited to, the following:

- Within the AVT WG, define the codec's payload format for use with the 
Real-time Transport Protocol (RTP).

- Collaborate with RMCAT and any other appropriate working groups in the 
Transport Area to identify important aspects of packet transmission over 
the Internet.

- Collaborate with RMCAT to understand the degree of rate adaptation 
desirable, and to reflect that understanding in the design of a codec 
that can adjust its transmission in a way that minimizes disruption to 
the video.

- Collaborate with working groups in the RAI Area to ensure that 
information about and negotiation of the codec can be easily represented 
at the signaling layer.

- Collaborate with working groups in the RAI Area such as CLUE and 
RTCWEB to ensure the codec can satisfy all of their video-related use cases.

The working group will coordinate with the ITU-T (Study group 16) and 
ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed 
codec RFC for co-publication by the ITU-T and ISO if they find that 
appropriate. To facilitate the potential for co-publication, and 
recognizing other SDOs like ISO/IEC (JTC1/SC29 WG11) are assessing video 
codec technologies for potential royalty-free standardization, the 
working group will seek on an ongoing basis where feasible to 
communicate through existing liaison channels and meetings, evaluate and 
share in-process proposals, test results, code bases, and IPR 
information, and facilitate parallel consideration of the working 
group's work-in-progress for royalty-free standardization under 
processes like the Common Patent Policy for ITU-T/ITU-R/ISO/IEC.

The Guidelines for Development of an Audio Codec within the IETF (RFC 
6569) will form the starting point for guidelines and requirements for 
achieving the forgoing objectives for video. The working group will 
modify them as necessary with lessons learned during that process (for 
example, specifying the use of English text as the normative definition 
of the codec instead of source code), refining them into a new document 
in accordance with the usual IETF procedures once consensus has been 
achieved.

A codec that can be widely implemented and easily distributed among 
application developers, service operators, and end users is preferred. 
Many existing codecs that might fulfill some or most of the technical 
attributes listed above are encumbered in various ways. For example, 
patent holders might require that those wishing to implement the codec 
in software, deploy the codec in a service, or distribute the codec in 
software or hardware need to request a license, enter into a business 
agreement, pay licensing fees or royalties, or attempt to adhere to 
other special conditions or restrictions.

Because such encumbrances have made it difficult to widely implement and 
easily distribute high-quality video codecs across the entire Internet 
community, the working group prefers unencumbered technologies in a way 
that is consistent with BCP 78 and BCP 79. In particular, the working 
group 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 working 
group will produce an unencumbered codec, the working group shall follow 
BCP 79, and adhere to the spirit of BCP 79. The working group cannot 
explicitly rule out the possibility of adopting encumbered technologies; 
however, the working group will try to avoid encumbered technologies 
that require royalties or other encumbrances that would prevent such 
technologies from being easy to redistribute and use. The working group 
should not proceed with publication of a codec RFC if there is consensus 
that it cannot "be widely implemented and easily distributed among 
application developers, service operators, and end users."

Deliverables

1. A set of Codec Standardization Guidelines that define the work 
processes of the working group. This document shall be Informational.

2. A set of technical Requirements. This document shall be Informational.

3. Specification of a codec that meets the agreed-upon requirements, in 
the form of an Internet-Draft that defines the codec algorithm. The text 
description of the codec shall describe the mandatory, recommended, and 
optional portions of the encoder and decoder. It is envisioned that this 
document shall be a Proposed Standard document.

4. A reference implementation of a software encoder and decoder. This 
will be in a separate document from the text description to allow it to 
be updated independently. It does not need to be standards-track.

5. Specification of a storage format for file transfer of the codec, to 
support non-interactive (HTTP) streaming, including live encoding and 
both progressive and chunked downloads. It is envisioned that this 
document shall be a Proposed Standard document.

6. A collection of test results, either from tests conducted by the 
working group or made publicly available elsewhere, characterizing the 
performance of the codec. This document shall be informational.

Goals and Milestones
TBD  WGLC on codec standardization guidelines
TBD  WGLC on requirements, liaise to other SDOs
TBD  Requirements to IESG (Informational)
TBD  Liaise requirements RFC to other SDOs
TBD  Codec standardization guidelines to IESG (Informational)
TBD  WGLC on codec specification, liaise to other SDOs
TBD  WGLC on reference implementation, liaise to other SDOs
TBD  Submit codec specification to IESG (Standards Track)
TBD  Submit reference implementation to IESG (Informational)
TBD  WGLC on storage format specification
TBD  Submit storage format specification to IESG (Standards Track)
TBD  WGLC on Testing document
TBD  Testing document to IESG
--- video-codec-charter-20130101.txt	2013-01-01 22:34:05.087381012 -0800
+++ video-codec-charter-20130108.txt	2013-01-08 22:53:25.258764448 -0800
@@ -131,11 +131,15 @@
 The working group will coordinate with the ITU-T (Study group 16) and
 ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed
 codec RFC for co-publication by the ITU-T and ISO if they find that
-appropriate. Information about codecs being standardized, including a
-detailed description of the requirements and goals, 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.
+appropriate. To facilitate the potential for co-publication, and
+recognizing other SDOs like ISO/IEC (JTC1/SC29 WG11) are assessing
+video codec technologies for potential royalty-free standardization,
+the working group will seek on an ongoing basis where feasible to
+communicate through existing liaison channels and meetings, evaluate
+and share in-process proposals, test results, code bases, and IPR
+information, and facilitate parallel consideration of the working
+group's work-in-progress for royalty-free standardization under
+processes like the Common Patent Policy for ITU-T/ITU-R/ISO/IEC.
 
 The Guidelines for Development of an Audio Codec within the IETF (RFC
 6569) will form the starting point for guidelines and requirements for

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 09 Jan 2013 11:58:01 -0500

On 01/09/2013 02:14 AM, Timothy B. Terriberry wrote:
> forming the codec WG), there was a great deal of argument against
> giving preference to the open source "business model" over other
> business models. The current phrasing represents the compromise that
> was reached at that time. This is an argument that I do not greatly
> wish to re-open. As with Opus, I don't think this will be a problem in
> practice.
Thanks for addressing my concerns and explaining the history of the
issue.  Hopefully it will be a non-issue going forward.  One can never
be too safe, though.

-- 
Libre Video
http://librevideo.org

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 15 Jan 2013 04:29:51 +0000

To put this bluntly, I don't think this charter is ready to go to the IESG. I'll go through in detail some of the reason why but at a high level, this is not a chatter that is going to provide the constraints and guidance for this work to be successful. It is a bunch of positing to allow the work to be approved when what I think we need is a set of guidelines to work within that plow the work to be completed in a timely fashion. Note I am not against this work, but I do want to have a charter that maximizes the odds of success and I think we can easily come up with a much better charter form the point of view of helping get the work done. 

Part of the problem is people, like myself, keep saying things and the charter never changes from the mozilla guy proposed long ago. If you look at the current version of the charter vs. the version from last august, no changes have been made to address the substantial issues. Perhaps that is because people have sent them in other forms that emails to the mailing lists because people were trying to build consensus for this. 

All of that said, I would be happy to book some time to have a conference call with a working document everyone could edit and try and write a charter that worked. I suspect that people largely agree on what they want, I just don't think this charter is going to help us get there quickly. 

On Jan 9, 2013, at 12:14 AM, Timothy B. Terriberry <[email-masked]> wrote:

> 
> Problem Statement
> 
> According to reports from developers of Internet video applications

The above is complete drivel to appear in a charter - it should say what we the IETF have consensus on. If the IETF has consensus on it, say that, if not… well, this is about as useful as saying that some internet users worried the world would end at the end of the mayan calendar. Overall, get rid of political positioning and get down to what the is WG is going to do, why, and how. 

> and operators of Internet video services, there is no standardized, high-quality video codec that meets all of the following three conditions:
> 
> 2. Is published by a recognized standards development organization (SDO) and therefore subject to clear change control and IPR disclosure rules.
> 
> 3. Can be widely implemented and easily distributed among application developers, service operators, and end users.

delete all this and instead rewrite the next paragraph to say what characteristics this codec is going to have 

> 
> There exist codecs that provide high quality encoding of video information, but that are not optimized for the actual conditions of the public, consumer-level, best-effort Internet. Such optimizations might include fast and flexible congestion control, such as the ability to change resolution without sending a keyframe; a simple means of handling packet loss in the face of reference frame re-ordering; the ability to join broadcast streams without waiting for a keyframe; special coding tools for screen captures to support remote services and desktop sharing; and many more. According to reports, this mismatch between design and deployment has hindered performance and interoperability of such codecs in Internet applications.
> 
> There exist codecs that can be widely implemented, but were not developed under the IPR rules of any SDO; according to reports, the lack of clarity in their IPR status has hindered adoption of such codecs in Internet applications.

Given the most likely path forward for this WG is endorse VP.next, I'd shy away from discussion of how codecs are developed and instead focus on how what you want to happen and how they were standardized. I think it is pretty clear that the SILK portion of opus was not "developed" under IETF IPR rules yet that was not a problem and I suspect this charter needs to be set up such that a similar situation would not be a problem. 

> 
> There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoption of such codecs in Internet applications.
> 
> According to application developers and service operators, a video codec that meets all three of these conditions would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily build innovative applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality video services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience.

I think most of the above is just confusing clutter in getting to a good charter and should be deleted. 

> 
> Objectives
> 
> The goal of this working group is to ensure the existence of a single high-quality video codec that can be widely

I'm very concerned that the "single" term dooms this effort to failure - more about that in other threads on how to avoid IPR  issues in video codecs 

> implemented and easily distributed among application developers, service operators, and end users. At present it appears that ensuring the existence of such a codec will require a development effort within the working group.
> 
> The core technical considerations for such a codec include, but are not necessarily limited to, the following:
> 
> 1. Designing for use in interactive applications (examples include, but are not limited to, point-to-point video calls, multi-party video conferencing, telepresence, teleoperation, and in-game video chat).

As I brought up in the BOF - I think we need to get specific in the charter about what things we will actually do, that are not done in pretty much all codecs, that are "good for interactive" 

> 
> 2. Addressing the real transport conditions of the Internet, such as the flexibility to rapidly respond to changing bandwidth availability and loss rates, or as otherwise identified and prioritized by the working group.

Again the above point is useless for a charter. It does not provide any real information or constraints. Say what we actually mean here. 

> 
> 3. Ensuring interoperability and clean integration with the Real-time Transport Protocol (RTP), including secure transport via SRTP.

seem uh, a bit obvious to need to be in the charter

> 
> 4. Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP). However, the result should not depend on the details of any particular signaling technology.

again, sort of irrelevant and missing RTSP

> 
> 5. Ensuring suitability for use in Internet applications and Web APIs, such as the HTML5 <video> tag, live streaming (e.g., via icecast), adaptive streaming (e.g., Dynamic Adaptive Streaming over HTTP (DASH), HTTP Live Streaming (HLS), etc.), the MediaSource API, the WebRTC APIs, proposed web recording APIs, and so on. However, the result should not depend on the details of any particular API.

What does the above mean - what constraints does this result in. I doubt we need to say much about any of this

> 
> Optimizing for very low bit rates (typically below 64 kbps) is out of scope because such work might necessitate specialized optimizations.

Get specific - saying "below 64 kbps is out of scope" I am fine with. Personally I think we should move this much higher than 64 

> 6. Ensuring the work is done under the IPR rules of the IETF.

given it's an IETF charter, this seem uh, oh I give up 

> 
> Although a codec produced by this working group or another standards organization might be used as a mandatory-to-implement technology by designers of particular Internet protocols, it is explicitly not a goal of the working group to produce a codec that will be mandated for use across the entire IETF or Internet community nor would their be any expectation that this would be the only mandatory-to-implement codec.
> 
> Based on the working group's analysis of the design space, the working group might determine that it needs to produce a codec with multiple modes of operation. However, it is not the goal of working group to produce more than one codec.
> 
> In completing its work, the working group should collaborate with other IETF working groups to complete particular tasks. These might include, but would not be limited to, the following:
> 
> - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP).

uh, small nit, wrong WG - how much review has this charter had :-)

> 
> - Collaborate with RMCAT and any other appropriate working groups in the Transport Area to identify important aspects of packet transmission over the Internet.

Lets list out the specific aspects now - the real issues comes to a video codec that smoothly adapt to wide range of bitrates - just define what is needed and write it down in the charter
 
> 
> - Collaborate with RMCAT to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the video.
> 
> - Collaborate with working groups in the RAI Area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer.

what will this above even mean in practice

> 
> - Collaborate with working groups in the RAI Area such as CLUE and RTCWEB to ensure the codec can satisfy all of their video-related use cases.

These WG do not even have requirements for codecs as far as I can tell so sort of hard to see how above will work

> 
> The working group will coordinate with the ITU-T (Study group 16) and ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed codec RFC for co-publication by the ITU-T and ISO if they find that appropriate. To facilitate the potential for co-publication, and recognizing other SDOs like ISO/IEC (JTC1/SC29 WG11) are assessing video codec technologies for potential royalty-free standardization, the working group will seek on an ongoing basis where feasible to communicate through existing liaison channels and meetings, evaluate and share in-process proposals, test results, code bases, and IPR information, and facilitate parallel consideration of the working group's work-in-progress for royalty-free standardization under processes like the Common Patent Policy for ITU-T/ITU-R/ISO/IEC.

The above paragraph loosely translated to "we will ignore other SDOs", if we want to actually reach out and try and have collaboration with other SDOs, we likely need to do that before chartering so we can create a joint charter. 

> 
> The Guidelines for Development of an Audio Codec within the IETF (RFC 6569) will form the starting point for guidelines and requirements for achieving the forgoing objectives for video. The working group will modify them as necessary with lessons learned during that process (for example, specifying the use of English text as the normative definition of the codec instead of source code), refining them into a new document in accordance with the usual IETF procedures once consensus has been achieved.

I think the above is a terrible idea as I suggest at the BOF. Some of the issues are around waiting to receive a bunch of proposal before moving forward, requiring a reference implication to be standardized, and so on. 

Could the next two paragraphs be reduced to one sentence ?

> A codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or attempt to adhere to other special conditions or restrictions.
> 
> Because such encumbrances have made it difficult to widely implement and easily distribute high-quality video codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the working group 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 working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. The working group should not proceed with publication of a codec RFC if there is consensus that it cannot "be widely implemented and easily distributed among application developers, service operators, and end users."
> 
> Deliverables
> 
> 1. A set of Codec Standardization Guidelines that define the work processes of the working group. This document shall be Informational.

In the codec WG, not sure the guidelines helped much  - but they used up a lot of time

> 3. Specification of a codec that meets the agreed-upon requirements, in the form of an Internet-Draft that defines the codec algorithm. The text description of the codec shall describe the mandatory, recommended, and optional portions of the encoder and decoder. It is envisioned that this document shall be a Proposed Standard document.

say above will be PS

> 
> 4. A reference implementation of a software encoder and decoder. This will be in a separate document from the text description to allow it to be updated independently. It does not need to be standards-track.

I think the above should not be part of IETF process. Of course I think there should and will be some open source implementation on github or something but IETF process does not work to review or update such a thing

> 
> 5. Specification of a storage format for file transfer of the codec, to support non-interactive (HTTP) streaming, including live encoding and both progressive and chunked downloads. It is envisioned that this document shall be a Proposed Standard document.

It seems to me that many people think we should use an existing storage format not invent a new one. If we are doing a new video storage format, I suggest that be a WG of it's own. 

> 
> 6. A collection of test results, either from tests conducted by the working group or made publicly available elsewhere, characterizing the performance of the codec. This document shall be informational.
> 
> Goals and Milestones

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Jan 2013 09:34:14 +0100

On 01/15/2013 05:29 AM, Cullen Jennings (fluffy) wrote:
> To put this bluntly, I don't think this charter is ready to go to the IESG. I'll go through in detail some of the reason why but at a high level, this is not a chatter that is going to provide the constraints and guidance for this work to be successful.
At a high level ... I think this may is a case where incremental 
improvement in charter language is not only useless, it may be actively 
harmful to getting the work done.
We know (from experience with standards processes in general) that this 
work isn't going to be done in 2013. On that timescale, things change - 
but the charter likely won't.

So a choice that appears perfectly reasonable to enshrine in the charter 
now (let-a-thousand-options-bloom, I'm looking at you) might seem 
completely unreasonable 6 months down the road - because this is a 
technical tradeoff, not a statement about the goals or the methods to 
get there.

In my years on the IESG, I became rather jaundiced with regard to the 
value of polishing charter language. I find that when it comes to 
getting work done, effective chairing, driving towards the goals, 
choosing and tasking editors, and making sure the formal processes that 
are required get started as soon as they are able to be started, and 
complete as soon as they're able to complete, are much more important 
than the embedding of precise definitions of terms and solutions into 
the charter.

We can spend another month on polishing charter language here, embedding 
a dozen technical choices in the charter (half of which we'll have to 
change before the end), and then send it off to the IESG so that they 
can get wider review in and outside the IETF community (where there will 
be objections and issues that this list has no possibility of 
predicting, in addition to the perfectly predictable ones), or we can 
say that this is "good enough", ship it to the IESG, and get the next 
step in the process started (IETF and liaison review).

That said ... I will also compose more text to the list about issues I 
see with the current text; that's just what one does at this time.

>   It is a bunch of positing to allow the work to be approved when what I think we need is a set of guidelines to work within that plow the work to be completed in a timely fashion. Note I am not against this work, but I do want to have a charter that maximizes the odds of success and I think we can easily come up with a much better charter form the point of view of helping get the work done.
>
> _______________________________________________
> video-codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/video-codec