RTP Payload Format for Raptor Forward Error Correction (FEC)
RFC 6682

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

(David Harrington) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

Comment (2011-11-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Robert's discuss and comment.

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-10-30)
No email
send info
- fecframework is now RFC6363 (I actually followed the reference
given so the wrong reference might have but didn't mislead)

(Russ Housley) No Objection

Comment (2011-10-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Gen-ART Review by Brian Carpenter on 30-Oct-2011 suggests some
  editorial changes.  Please consider them.

  Typo in page header title.  It says: RTP Payload Fromat for Raptor
  s/Fromat/Format/

  There are several places where an upper-case MAY is used where a
  plain English lower case "may" would be fine:
  - all three MAYs in the Introduction;
  - the first sentence of section 3; and
  - all three MAYs in the last paragraph of the Security Conisderations.

(Pete Resnick) (was Discuss) No Objection

Comment (2011-11-25)
No email
send info
A bunch of comments on 2119 usage:

Overall: I'm not a big fan of SHALL instead of MUST; it seems to me that MUST works better throughout all of your uses.

Specific problems:

Section 3: [Addressed]

4.1: [First issue addressed]

I'm not clear on why the marker bit is labeled with a SHALL. The marker bit is set to 1 for the last packet and is otherwise 0. I suppose it is a requirement, but I can't imagine how an implementation could decide to set the marker bit to 0 for a non-final packet. Seems like a silly use of SHALL. Same with the definition and use of timestamp. I don't think you need 2119 keywords here.

4.3: [Addressed]

Section 6 [See DISCUSS]

Section 7: [Addressed]

Section 8: [Addressed]

Section 11: [Addressed]

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2011-11-02)
No email
send info
While it's not a hard requirement at the moment, I think it would help
the quality of RTP payload documents to run them through as PAYLOAD
working group items. Please consider taking that approach with future
payload format specifications.

(Sean Turner) (was Discuss) No Objection