RTP Payload Format for Raptor Forward Error Correction (FEC)
draft-ietf-fecframe-rtp-raptor-07

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

(David Harrington; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

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

(Jari Arkko; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pete Resnick; former steering group member) (was Discuss) No Objection

No Objection (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]

(Ralph Droms; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) (was Discuss) No Objection

No Objection (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.

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (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.

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (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)

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Wesley Eddy; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info