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

Comment (2007-04-16 for -** No value found for 'p.get_dochistory.rev' **)
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.]

(Jari Arkko; former steering group member) Yes

Yes ()
No email
send info

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

Yes ()
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection ()
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ()
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Ward; former steering group member) No Objection

No Objection ()
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ()
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

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

No Objection ()
No email
send info

(Sam Hartman; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (2007-04-16 for -** No value found for 'p.get_dochistory.rev' **)
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!