Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME
draft-ietf-fecframe-ldpc-04

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

(Martin Stiemerling) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-10-08 for -03)
No email
send info
  Please consider the comments provided in the Gen-ART Review by
  Meral Shirazipour on 1-Oct-2012.  You can find it here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07805.html

Barry Leiba No Objection

Comment (2012-10-02 for -02)
No email
send info
I have no objection to this document, and no blocking comments.  These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

Throughout:
All of the "MAY" words in here seem wrong: they're describing conditions that might exist, not specifying directives for making choices (unless I'm mis-reading it).  You MUST consider various things when you construct an ADU block.  One of those various things may or might (but not MAY) be factor A.  I think all the "MAY"s in the document should be lower case (or be replaced by "might"):
  - the target use-case MAY have real-time constraints
  - [the real-time constraints] MAY define a maximum ADU block size
  - a codec MAY impose other limitations on the maximum source block size
  - The source ADU flows MAY have real-time constraints.
  - Reed-Solomon codes or 2D parity check codes MAY be more appropriate.


-- Section 8 --
   Values of FEC Encoding IDs are subject to IANA registration.
   [RFC6363] defines general guidelines on IANA considerations.  In
   particular it defines a registry called FEC Framework (FECFRAME) FEC
   Encoding IDs whose values are granted on an IETF Consensus basis.

IANA notes that "IETF Review" is the right term and suggests changing this.  I suggest just removing the paragraph; it's not necessary, and it doesn't seem to have any value at all.  You can move the reference to RFC 6363 to the next paragraph, which can otherwise remain as it is.

(Pete Resnick) (was Discuss) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection