RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR)
RFC 5993

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

Lars Eggert No Objection

(Robert Sparks; former steering group member) Yes

Yes ()
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-05-20)
No email
send info
Section 5.2

How likely is it that a future specification will want to assign meaning to the other FT setting? If it is likely, you may want to consider a registry.

---

Section 7.1

There are two instances of "RFC XXXX" in this section. I assume you want the RFC Editor to insert the number of this RFC when published, and that you want this reflected in the work done by IANA.

A note to this effect in the document as 
-- RFC EDITOR AND IANA please blah, blah
would be helpful. Or put it in the ballot write-up.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2010-05-20)
No email
send info
7.1.  Media Type Definition

   The media subtype
   name contains "-08" to avoid potential conflict with any earlier
   drafts of GSM-HR RTP payload types that aren't bit compatible.

This text really belongs to the following section, which you left empty:

  [...]

   Interoperability considerations:

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (2010-05-18)
No email
send info
Just some minor edits:

Sec 3: r/network provides with mobile/network provides mobile

Sec 3: r/is one of the speech codecs that are used in/is one of the speech codecs used in

Sec 3: Should recommended and should in the last paragraph be capitalized?

(Stewart Bryant; former steering group member) No Objection

No Objection ()
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (2010-05-18)
No email
send info
one nitpick - 4855 specifically identifies payload formats that could be used to hide data
as a security risk.  I believe that this format provides very limited opportunities for data hiding,
since the amount of data is fairly small and significant amounts of data would likely be audible (and not very effectively hidden!)

Perhaps a sentence or two in security considerations would be good - it would demonstrate that
all aspects of 4855's security considerations were considered.