Forward Error Correction (FEC) Building Block
draft-ietf-rmt-fec-bb-revised-07

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

Lars Eggert No Objection

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.]

(Jari Arkko; former steering group member) Yes

(Magnus Westerlund; former steering group member) (was Discuss, Yes) Yes

(Chris Newman; former steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(David Ward; former steering group member) No Objection

(Jon Peterson; former steering group member) No Objection

(Mark Townsley; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) (was Discuss) No Objection

(Sam Hartman; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection

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!