Forward Error Correction (FEC) Framework
draft-ietf-fecframe-framework-15
Yes
(David Harrington)
No Objection
(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Lars Eggert)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Tim Polk)
Note: This ballot was opened for revision 15 and is now closed.
David Harrington Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-09-22)
Unknown
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/
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2010-09-22)
Unknown
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"?
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre 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
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2010-09-21)
Unknown
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.
Sean Turner Former IESG member
(was Discuss, No Record, No Objection)
No Objection
No Objection
(2010-09-23)
Unknown
Sec 9, penultimate paragraph: Add informative reference for IPsec in 2nd to last paragraph.
Stewart Bryant Former IESG member
No Objection
No Objection
(2010-09-18)
Unknown
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.
Tim Polk Former IESG member
No Objection
No Objection
(2010-09-23)
Unknown
I support Sean's discuss position.