Skip to main content

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

Yes

(Martin Stiemerling)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Sean Turner)
(Stephen Farrell)
(Stewart Bryant)
(Wesley Eddy)

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

Martin Stiemerling Former IESG member
Yes
Yes (for -02) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2012-10-02 for -02) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2012-10-08 for -03) Unknown
  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
Sean Turner Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown