Guidelines for Development of an Audio Codec within the IETF
RFC 6569

Note: This ballot was opened for revision 08 and is now closed.

(Robert Sparks) Yes

(Jari Arkko) No Objection

Comment (2011-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 6 would be much improved if bullet item 2 (IETF's own codec) stated that such codecs MUST be entirely separate in terms of their name, code points, and usage in applications from other codecs. That is, if IETF develops its own codec, it should assign specific code points for its use as well, not, e.g., reuse some code points that were already being used by a codec developed elsewhere.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-11-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nit

S/agains them/against them/

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The WG charter says quite a lot about liaising its work with other SDOs. Although this I-D may be a bit foundational, it would not be harmful to offer other SDOs the chance to comment on the way we plan to proceed.

I sense that a lot of voices were raised in the WG, and that is good, but I son't see any mention of communication with other SDOs in the write-up.

I should like the ADs and chairs to ensure they have in place a proper mechanism to ensure the right documents are liaised at the right time in the cycle.

(Stephen Farrell) No Objection

Comment (2011-11-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- I'm wondering if this is really only about audio - the title implies
its more general but the body of the document is only specifically 
about audio. Suggest maybe adding audio to the title if that's
correct and matches the wg's intent.

- Step 5 of the list in section 2: this doesn't specify criteria
for "sufficient" but I expected that's a normal WG consensus call for
the lucky chairs. More interesting though is whether this has already
happened or not? If so, then you can and maybe should use the 
past-tense. If not, when is this process going to be run?

- p5 mentions "the requirements document" - why not add a reference?

- p9 says errata "should be maintained" - that happens for all RFCs
already.

(Russ Housley) No Objection

Comment (2011-11-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the comments in the Gen-ART Review by Martin Thomson
  on 11-Oct-2011.  The comment are here:

  http://www.ietf.org/mail-archive/web/gen-art/current/msg06791.html

(Pete Resnick) No Objection

Comment (2011-11-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- I tend to agree with Stephen's comment that this document really is about an audio codec and it should say that. But let me go further and say that this document really is about *the* audio codec being developed in the codec working group. The document has some text that alludes to that (e.g., the title mentions "the Codec" and there are several mentions of "the group" in the document), but other places that is not clear and it sounds like it is giving guidelines for *any* codec (audio, video, otherwise) in *any* IETF working group (e.g., the intro says, "This document describes a suggested process for work at the IETF..."). I don't think this document intends to do the latter, and it would be useful to clarify some of that language.

- The intro says "This document describes a suggested process...", and elsewhere it is worded as a "suggestion". I wouldn't mind if that got tightened up into more of a "guideline" or a "process" that the WG *will* follow. Of course, if the WG came to consensus that they wanted some latitude to ignore this guidance from time to time, I have no strong objection to leaving in the softer language.

[For the moment, I will make the following a comment. However, if others on the IESG feel strongly about it, I can switch it to a discuss.]

- I don't think BCP 79's language about "preferring" no-known-IPR or royalty-free-IPR technology is normative; I think it's descriptive. That is, it is fine if this particular WG wants to explicitly prefer no-known-IPR (or, secondarily, royalty-free-IPR), but don't blame BCP 79 as if it says that the WG *ought* to prefer them. I think the statements regarding doing things "in accordance with BCP 79" are bogus. They should be replaced with statements that the WG is doing things "as described by BCP 79".

(Dan Romascanu) (was Discuss) No Objection

(Sean Turner) No Objection

Comment (2011-11-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
So I'm not sure you need to do this, but a lot of times WG's develop requirements drafts and then they fret over whether to progress the before the solution draft or keep it as a living draft until after the solution draft is published.  If the WG has considered this, then it might be worth saying whether or not you're going to progress the requirements draft prior to completing the solutions draft.

You could add an informative reference to RFC 4648 for base64.

(Peter Saint-Andre) Recuse

Comment (2011-11-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Although I strongly support this work, I am recusing myself because I co-authored the first several versions of draft-valin-codec-guidelines, which was used as the starting point for the WG document.