Raptor Forward Error Correction (FEC) Schemes for FECFRAME
draft-ietf-fecframe-raptor-11
Yes
(David Harrington)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Pete Resnick)
(Ralph Droms)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 10 and is now closed.
David Harrington Former IESG member
Yes
Yes
(for -10)
Unknown
Martin Stiemerling Former IESG member
(was Discuss)
Yes
Yes
(2012-05-14)
Unknown
All cleared and thanks for addressing the points.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -10)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -10)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2012-04-23 for -10)
Unknown
4.1. Definitions This document uses definitions that apply to FEC Framework in general as defined in [RFC6363]. In addition, this document uses the following definitions: Not sure what "that apply to FEC Framework in general" means. Don't you want to say something such as The FEC-specific terminology used in this document is defined in [RFC6363]. In this document, as in [RFC6363], the first letter of each FEC-specific is capitalized along with the new terms defined here:
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -10)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(for -10)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2012-04-24 for -10)
Unknown
In section 7.2.1.2 did you mean to point to 6.2.1.2 instead of 6.2.2?
Ron Bonica Former IESG member
No Objection
No Objection
(for -10)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2012-04-24 for -10)
Unknown
Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 18-Mar-2012. The review can be found at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07284.html
Sean Turner Former IESG member
No Objection
No Objection
(2012-04-25 for -10)
Unknown
I guess I'm with Stephen on the security considerations it should really also point to RFCs 5053 or 6330.
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-04-23 for -10)
Unknown
- Its not clear to me whether the "device" mentioned in the IPR declaration's licensing section really only means h/w devices or not, or could badly impact e.g. an OSS implementation of this draft. I assume the WG have considered this and are happy with the idea of the license being specific to a "device" or at least don't seem to care (as implied by the write-up). - 6.2.1.2 - if the last octet is omitted then all the reserved bits aren't sent. Would it be worth noting that it'd not be safe to omit that octet if someone defines meanings for some of those reserved bits in future? Would "MAY be omitted" be better (i.e. use a 2119 keyword)? Finally, it'd have been nice if you had said that that octet SHOULD be sent or SHOULD be omitted - why not do that? - 7.1 - Would it be better to be explicit here about how the padding with zeros is done? I.e., rfc6330 says that symbols K through K'-1 are the padding symbols, the same is true here I think but good to say so, if so rather than forcing the reader to check in rfc6330. - 8.1.3 - Similar question about padding, though here the answer is obvious I guess, but still maybe no harm saying. - Section 9 defers to 6363 for security considerations, but 6330's and 5053's (identical?) security considerations seem more concrete, e.g. they RECOMMEND using something like TELSA, whereas 6363 eventually says "implement IPsec" but doesn't say much about what to use. It'd be good to be clearer about what, if anything, is mandatory-to-implement or SHOULD be used here. (This isn't a DISCUSS because all those RFCs are normative references so in theory implementing this means doing all of the above I guess.)
Stewart Bryant Former IESG member
No Objection
No Objection
(for -10)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -10)
Unknown