Forward Error Correction (FEC) Building Block
RFC 5052

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

(Jari Arkko) Yes

(Magnus Westerlund) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

Comment (2007-04-16 for -)
No email
send info
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.]

(Sam Hartman) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2007-04-16 for -)
No email
send info
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!

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection