Subject: [codec] the form of a contribution

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Mar 2010 11:54:31 -0700

<hat type='chair'/>

On the informal call just now, Raymond Chen raised a good point about
how to contribute a codec to the WG. In particular: does a contribution
need to be provided in the form of an Internet-Draft?

BCP 79 does not restrict contributions to Internet-Drafts, because it
defines "IETF Contribution" as follows:

***

   c. "IETF Contribution": any submission to the IETF intended by the
      Contributor for publication as all or part of an Internet-Draft or
      RFC (except for RFC Editor Contributions described below) and any
      statement made within the context of an IETF activity.  Such
      statements include oral statements in IETF sessions, as well as
      written and electronic communications made at any time or place,
      which are addressed to:

      o  the IETF plenary session,
      o  any IETF working group or portion thereof,
      o  the IESG, or any member thereof on behalf of the IESG,
      o  the IAB or any member thereof on behalf of the IAB,
      o  any IETF mailing list, including the IETF list itself, any
         working group or design team list, or any other list
         functioning under IETF auspices,
      o  the RFC Editor or the Internet-Drafts function (except for RFC
         Editor Contributions described below).

      Statements made outside of an IETF session, mailing list or other
      function, that are clearly not intended to be input to an IETF
      activity, group or function, are not IETF Contributions in the
      context of this document.

***

It seems to me that "any statement made within the context of an IETF
activity" might include:

1. Oral statements addressed to the Codec WG in the form of a
presentation during a WG session.

2. Posts to this list.

3. Modifications to the WG wiki pages if we decide to track
contributions that way.

Discussion within the WG would be appreciated so that the group can
determine how it would like to receive contributed codecs.

Peter

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

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Tue, 09 Mar 2010 14:19:54 -0500

> need to be provided in the form of an Internet-Draft?

1.  For legal purposes, clearly not.  Virtually any statement in IETF
context can be a contribution.

2.  Internet-Drafts are a preferred form for precise contributions.  I
don't have an opinion on the relative merits of I-Ds over other forms of
technical literature for evaluating useful technologies.

--Ben

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 9 Mar 2010 23:23:49 -0500

> context can be a contribution.

s/can be/is/

Read the Note Well.

Regards
Marshall

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 10 Mar 2010 10:55:36 +0100

Hi all,

I think you folks are mixing IPR policy with Internet standards process.

Peter & Marshall are absolutely right that everything that's said or written
in the IETF context is a Contribution, per Note Well and and the assorted
IPR policy documents.

> need to be provided in the form of an Internet-Draft?

I believe that RFC2026 mandates that anything that wishes to advance to an
IETF RFC (standard's track, for example), needs to be published first as an
Internet Draft.  It is my understanding that the IESG acts on publication
requests of Internet Drafts, and not on any other documents.

If the context of the question was "Has a new codec to be proposed in the
form of an Internet Draft, for consideration by the group", the answer is
Yes.  Pointers to ongoing open source projects, for example, are
insufficient.  

If the context of the question was "Is there a requirement for a written
contribution to be acted upon in the IETF, the way things are in the ITU or
in ETSI", the answer is No.  In the IETF, a group can and does act on oral
and mailing list input just as well as on Internet Drafts.  However, before
approval (ideally: way before approval), all content needs to be written
down in an Internet Draft.

Stephan

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 10 Mar 2010 06:54:30 -0500

> Yes.  Pointers to ongoing open source projects, for example, are

If the goal is to get your codec become an RFC, I agree that an I-D is 
needed. However, I don't see how a draft is necessary just for 
contributing technology towards a common codec that will eventually 
published as an RFC, which is the case here. For example, if we wished 
to use some technology from G.722, would we have to require the ITU-T to 
submit an I-D on G.722? I believe the answer is no. Again, I understand 
that the codec that gets created from these multiple contributions has 
to be an I-D. Does this make sense?

	Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Wed, 10 Mar 2010 14:06:41 +0200

Hi,
This leads to a question what codec documentation is needed. The source code
is not a codec description, so a draft describing the codec will be useful.
There also a need to describe the quality test results.

As for the source code, as long as it is an individual code and the IETF
does not have change control it is simple, the question is what happens once
it is adopted as a WG document. If someone suggests to add to it some code,
how is it handled (what reasoning is required to enable people to accept or
reject the proposal) and what is the common WG source code that is the base
for the proposed change.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jean-Marc Valin
> Sent: Wednesday, March 10, 2010 1:55 PM
> To: Stephan Wenger
> Cc: Codec WG
> Subject: Re: [codec] the form of a contribution
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 10 Mar 2010 09:42:52 -0500

> reject the proposal) and what is the common WG source code that is the base

You mean adding code during development or once the codec is "final".
Obviously, once the codec is published as RFC, changing the code in a way
that break compatibility would require extraordinary reasons (e.g. a najor
security issue that cannot be resolved otherwise), because in general you
do not break bit-stream compatibility. So far all the changes/additions
I've seen to speech codec standards have been in ways that preserve
compatibility.

	Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Wed, 10 Mar 2010 18:45:35 +0200

Jean-Marc,
I meant during development, once an individual proposal (like the current 3
or 4 codec that will be presented) is accepted by the WG as a WG item. If
you see a different working mode, it should be clear and agreed by the WG.

As for your comment about later change, my understanding of the IETF process
is that anyone can bring an update to a published RFC and the WG can decide
if to accept it. If bit-stream compatibility is an issue than it should be
stated in the published RFC. It should be stated what is allowed as
extensions or updates to the published document.

Roni Even

> From: Jean-Marc Valin [mailto:[email-masked]]
> Sent: Wednesday, March 10, 2010 4:43 PM
> To: Roni Even
> Cc: 'Jean-Marc Valin'; 'Stephan Wenger'; 'Codec WG'

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 10 Mar 2010 19:45:54 +0100

> to be an I-D. Does this make sense?

Yes, it makes sense.

I would, however, suggest that it is in the interest of everyone here that
any substantial Contribution, that cannot be simply referenced by a document
from another SDO, be documented in the form of an I-D.  What I was worried
about is that too much informality early on may lead to huge integration
problems later.  One example: if we were "accepting" an informal
contribution of source code licensed under the GPL, with an unknown set of
contributors, we would have real trouble in including this source code in
our RFCs.  (If the contributors are all known, and would all be willing to
license their work also under our simplified BSD-style license as required
by the IETF Trust, then things would be different).

To make things complete, the WG could decide that an outside codec (from the
ITU or another recognized SDO) is fulfilling the requirements in full.  In
this case, I guess one outcome of the WG could be an RFC that simply
recommends that codec, referring to it by reference only, as the preferred
Internet Wideband Speech Codec (or whatever appropriate name you guys can
come up with), and be done.  The codec itself would not have to be
ASCII-fied, and Note Well etc. would not apply.

Stephan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Mar 2010 12:25:09 -0700

<hat type='chair'/>

> ASCII-fied, and Note Well etc. would not apply.

Yes, that is one possible outcome. It would certainly save us a lot of
work. :)

However, we'd need to be clear on the requirements first -- which we
need whether we design something new, take the best ideas from a number
of different contributed codecs, or accept an existing codec as "good
enough" to fulfill the requirements. That's why it's so important for
people on this list to review draft-ietf-codec-requirements-00 and
provide technical feedback on the list before IETF 77...

Peter

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