Forward Error Correction (FEC) Building Block
draft-ietf-rmt-fec-bb-revised-07
Yes
(Jari Arkko)
(Magnus Westerlund)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 07 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2007-04-16)
Unknown
Section 1., paragraph 1: > This document is a > product of the IETF RMT WG and follows the general guidelines > provided in [5]. We don't typically mention which WGs have produced documents. Section 2., paragraph 3: > It was the stated intent of the RMT working group to re-submit this > specification as an IETF Proposed Standard in due course. We don't typically talk about intentions of WGs or people in our documents. [Editing nits sent to the authors directly.]
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2007-04-16)
Unknown
As noted in the writeup, the current version does not differ significantly from RFC 3452. The changes do not appear to impact the security considerations, and the document repeats the security considerations from RFC 3452. Since the document was previously approved with these security considerations, I am entering this as a comment rather than a discuss. However, I am uncomfortable with the first sentence in the security considerations section: "Data delivery can be subject to denial-of-service attacks by attackers which send corrupted packets that are accepted as legitimate by receivers. While it is true that data delivery without authentication "can be subject to denial-of-service attacks", there can be other consequences as well. RFC3453 says "[b]y injecting corrupted encoding symbols, they are accepted as valid encoding symbols by a receiver, which *at the very least*, is an effective denial of service attack." (My emphasis on "at the very least".) It would be nice if the security considerations addressed some of the other potential consequences!