Subject: [codec] Review of the proposed charter

From: "Roni Even" <[email-masked]>
Date: Tue, 27 Oct 2009 17:14:42 +0200

Hi,

I read the proposed charter and in general is a good start I still have some
comments

1.  In the deliverable section "Guidelines that define the work process of
the group, using draft-valin-codec-guidelines as the basis for achieving
consensus. This document shall be Informational." Does this mean that once
the charter is approved we are also approving the mentioned ID as a WG
document for guideline. Otherwise I think that the text should be
"Guidelines that define the work process of the group. This document shall
be Informational."

2.  The same comment for the next section about requirements. I also think
that if the requirement will include some metrics used to test the codec
this draft should have Normative context and may be a standard track
document

3.  The last section of the deliverable "Specification of one or more codecs
that meet the agreed-upon requirements," I think that if the proposed
working group is going to define more than one codec, each codec should have
his own requirement draft giving motivation and the specific requirement for
having a different codec from the first proposed one that will be developed
based on the requirement document from the previous section. I do not think
that one set of requirement merit more than one codec.

Thanks

Roni Even

  _____

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Oct 2009 14:40:32 -0600

On 10/27/09 9:14 AM, Roni Even wrote:
> Hi,
> 
> I read the proposed charter and in general is a good start I still have
> some comments
> 
> 1.  In the deliverable section "Guidelines that define the work process
> of the group, using draft-valin-codec-guidelines as the basis for
> achieving consensus. This document shall be Informational." Does this
> mean that once the charter is approved we are also approving the
> mentioned ID as a WG document for guideline. Otherwise I think that the
> text should be  "Guidelines that define the work process of the group.
> This document shall be Informational."
> 
> 2.  The same comment for the next section about requirements. 

The charter is the WG's contract with the IESG. I think it is much
better to show the IESG that the group has been actively working on both
the guidelines and the requirements by pointing to specific I-Ds,
especially because the major issue raised in Stockholm was the lack of
clear guidelines and requirements. IMHO draft-valin-codec-guidelines and
draft-valin-codec-requirements would form the basis of discussion by the
WG (if formed), so yes I think the WG would adopt them as WG items,
although I think that a final decision will be up to the WG if and when
it is formed.

> I also
> think that if the requirement will include some metrics used to test the
> codec this draft should have Normative context and may be a standard
> track document

Do you see that as a separate document or as part of the requirements
document?

> 3.  The last section of the deliverable "Specification of one or more
> codecs that meet the agreed-upon requirements," I think that if the
> proposed working group is going to define more than one codec, each
> codec should have his own requirement draft giving motivation and the
> specific requirement for having a different codec from the first
> proposed one that will be developed based on the requirement document
> from the previous section. I do not think that one set of requirement
> merit more than one codec.

That seems unnecessarily complex. IMHO it would be simpler for the
requirements document to define the requirements in as much detail as
possible, while leaving some requirements flexible by specifying ranges
of acceptable behavior or performance, dimensions that a particular
codec could legitimately optimize for, etc. Then each codec spec would
state the more particular requirements it has tried to meet, without
writing a separate requirements document for each codec spec. That
sounds like an awful lot of documents for very little benefit, but I
think that these editorial issues aren't something that needs to be in
the charter and can be worked out by the WG (if approved).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Roni Even" <[email-masked]>
Date: Tue, 27 Oct 2009 23:16:58 +0200

Hi Peter,
I think that you can mention the documents to the IESG but they cannot be part of the deliverable since they are ID that did not go yet through any consensus.

As for you response on multiple codec, it look to me that the group will be a codec factory where anyone can define a codec based on part of the requirements and still be inline with the charter. I find it strange that you suggest that the group will develop requirements that do not need to be fully answered by one codec and let everybody select part of them and develop a codec. I am not aware that the IETF does two competing solutions for the same requirement document.

When the discussion on doing a codec in the IETF was started it was about defining a codec for wideband audio that will be easily available in order to help with deployment of wideband in Internet applications. Doing multiple codecs will not answer this basic need of interoperability.

Regards
Roni Even

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Tuesday, October 27, 2009 10:41 PM
> To: Roni Even
> Cc: [email-masked]
> Subject: Re: [codec] Review of the proposed charter
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrnWsAACgkQNL8k5A2w/vzhegCgpZvE8dOdAfvWeERLi/VZY5rC
> 4/YAnisQQgAQXKrJARwBbufeJt4BioWZ
> =c5PQ
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Oct 2009 16:11:56 -0600

On 10/27/09 3:16 PM, Roni Even wrote:
> Hi Peter, I think that you can mention the documents to the IESG but
> they cannot be part of the deliverable since they are ID that did not
> go yet through any consensus.

I freely grant that consensus has not yet been reached regarding the
guidelines and requirements I-Ds, but to expect consensus before a WG
has even been formed is a novel interpretation of the Internet Standards
Process! The proposed charter states that these I-Ds will form the basis
for discussion within the WG, hopefully leading to eventual consensus,
WGLC, and IETF Last Call. That is the normal process for discussion
within the IETF. Do you suggest that consensus should be reached (and by
whom?) before a charter can even mention an I-D as the basis for further
discussion and refinement? And on what basis could such consensus be
reached, given that a WG has not even been formed yet? This is a
Catch-22 and would prevent the formation of any WG, unless you suggest a
process by which IETF LC would be necessary for WG formation.

> As for you response on multiple codec, it look to me that the group
> will be a codec factory where anyone can define a codec based on part
> of the requirements and still be inline with the charter. 

The proposed charter states:

###

The group might produce only one codec or it might produce multiple
codecs; however, to reduce confusion in the marketplace it shall
endeavor to produce as few codecs as possible, and in any case shall not
function as a "codec factory" that produces a large number of codecs.

###

That clearly states the preference of the group to NOT be a codec factory.

> I find it
> strange that you suggest that the group will develop requirements
> that do not need to be fully answered by one codec and let everybody
> select part of them and develop a codec. 

What I am suggesting is a conceptual approach. Let me provide an
example. The requirements document as it stands today states that the
operating space includes medium delay (20-30 ms) applications from
narrowband (8 kb/s to 16 kb/s) to full band (32 to 80 kb/s) and very low
delay (< 10 ms) applications from super wideband (32 to 80 kb/s) to full
band (48 to 128 kb/s). The requirements document does not say that we
must produce "one codec to bind them all" -- one codec that will work
optimally for everything from medium delay + narrowband to very low
delay + full band. Yes, that would be great, but perhaps it is not
possible. IMHO we might produce two codecs, one that is optimized for
certain parts of the operating space and another that is optimized for
oher parts of the operating space. To say that the WG must produce one
and only codec for all parts of the operating space implies that the WG
would need to ignore facts the group might discover as it tries to solve
the problem.

> I am not aware that the IETF
> does two competing solutions for the same requirement document.

RFC 2779 defined requirements that have been met by both the XMPP WG and
the SIMPLE WG.

However, in the codec space the solutions would not be competing, they
would be complementary because they would be optimized for different
aspects of the operating space.

Would it help to add some text to the effect that, if the WG finds that
it must produce multiple codecs, it would try to produce codecs that are
complementary instead of competing?

> When the discussion on doing a codec in the IETF was started it was
> about defining a codec for wideband audio that will be easily
> available in order to help with deployment of wideband in Internet
> applications. Doing multiple codecs will not answer this basic need
> of interoperability.

The world seems to contain dozens or hundreds of codecs that are
optimized for different aspects of media encoding and communication. In
fact other SDOs have produced many, many codecs without, it seems, doing
permanent damage to the Internet. Yes, ideally an IETF Codec WG would
produce one codec to bind them all, but to require that in the charter
seems quite unhelpful to me because it would unnecessarily restrict the
WG from finding optimal solutions.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Oct 2009 10:34:22 -0600

> process by which IETF LC would be necessary for WG formation.

Hi Roni,

I'm sorry, I misunderstood your point. We mention the existing I-Ds in
two places. In the "Objectives" section we say:

###

Work processes and technical requirements for achieving the foregoing
objectives are outlined in draft-valin-codec-guidelines and
draft-valin-codec-requirements respectively; these documents will form
the starting point for working toward consensus and will be refined by
the group in accordance with the usual IETF procedures.

###

And in the "Deliverables" section we say:

###

1. Guidelines that define the work process of the group, using
draft-valin-codec-guidelines as the starting point for working toward
consensus. This document shall be Informational.

2. Detailed technical requirements, using draft-valin-codec-requirements
as the starting point for working toward consensus.  This document
shall be Informational.

###

I thought you wanted to remove these mentions in both places. I think
you're right that the "Deliverables" section would be better without
mentioning specific drafts, because the WG needs to officially accept
I-Ds as WG items. So I think the "Deliverables" section needs to say:

###

1. Guidelines that define the work process of the group. This
document shall be Informational.

2. Detailed technical requirements. This document shall be
Informational.

###

My apologies for the misunderstanding.

Do you think it is acceptable to mention these I-Ds earlier in the
charter text?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: "Roni Even" <[email-masked]>
Date: Wed, 28 Oct 2009 23:00:31 +0200

Peter,
Thanks, I am trying to be helpful and this was exactly my meaning on the first two items in the deliverables section.
As for the objective I think it is acceptable to mention documents, it just need to be clear that they are not yet based on full consensus as can be seen on the mailing list and that there may be other requirement documents.

The only point I still feel is open is about how to decide which proposed codecs are within the charter of the group. Having it too open as it is now, will not help you with IESG, but this is my personal view based on my experience with my WG charter.

Roni Even

> Sent: Wednesday, October 28, 2009 6:34 PM
> To: Roni Even
> Cc: [email-masked]
> iEYEARECAAYFAkroco0ACgkQNL8k5A2w/vyNBwCfemx1ZqexcTkv4JJBMPqiJh4x
> GaEAnikpDFIYfYudGyvAPOkLwW5vpICd
> =owS6