Forward Error Correction (FEC) Framework
RFC 6363

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

(David Harrington) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

Comment (2010-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Ari Keranen asked about this:

5.6. FEC Scheme requirements

    3.  The name, type, semantics and text value encoding rules for zero
        or more FEC Scheme-specific FEC Framework Configuration
        Information elements.  Names must conform to the "name"
        production and values encodings to the "value" production defined
        in Section 5.5

What text in the section 5.5 defines these productions? Or do you mean 
the text "where the valid element names and value ranges are defined by 
the FEC Scheme"? If so, it could be better to simply state it here 
rather than reference to section 5.5.

Also, you probably mean "value encodings" instead of "values encodings"?

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2010-09-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The term "ADU" is not defined until Page 9, but is used many times before this point in the document. It would assist the reader if it were defined earlier in the document.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-09-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Thanks for this document.

I have a Comment that might generate a substantial piece of work for 
you. I do not feel strongly enough to enter a Discuss, but it would be
great if you thought about it and maybe added to the document.

It would be helpful, I think, if a framework/architecture like this 
included a discussion of how the systems and networks described are
operated and managed. You might look at RFC 5706 for guidance.

--

I have a cople minor comments about Section 8

      The authors of this draft are primarily interested in applications

s/draft/document/

      We propose a third approach, which is to require at a minimum that
      the use of this framework with any given application, in any given
      environment, does not cause congestion issues which the
      application alone would not itself cause i.e. the use of this
      framework must not make things worse.

This is a Standards Track document. s/propose/define/

(Russ Housley) (was Discuss) No Objection

Comment (2010-09-21)
No email
send info
  Please consider comments from the Gen-ART Review by Joel Halpern on
  19-Sep-2010:

  The text in section 8 seems to imply that cellular devices experience
  high loss rates.  This is misleading, as radio protocols generally
  provide sufficient flow control and retransmission so as to bring the
  link behavior to levels similar to that of other media.  Please either
  recheck the assumptions being made, or consider removing the reference
  to cellular links.
  
  The definition of Application Data Unit should include an indication
  that this is referred to as an ADU.

(Alexey Melnikov) (was Discuss) No Objection

(Tim Polk) No Objection

Comment (2010-09-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Sean's discuss position.

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) (was Discuss) No Objection

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) (was Discuss, No Record, No Objection) No Objection

Comment (2010-09-23)
No email
send info
Sec 9, penultimate paragraph: Add informative reference for IPsec in 2nd to last paragraph.