Skip to main content

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)

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!