Skip to main content

Last Call Review of draft-ietf-mmusic-delayed-duplication-02
review-ietf-mmusic-delayed-duplication-02-secdir-lc-perlman-2013-09-19-00

Request Review of draft-ietf-mmusic-delayed-duplication
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-24
Requested 2013-09-12
Authors Ali C. Begen , Yiqun Cai , Heidi Ou
Draft last updated 2013-09-19
Completed reviews Genart Last Call review of -02 by Francis Dupont (diff)
Secdir Last Call review of -02 by Radia Perlman (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-mmusic-delayed-duplication-02-secdir-lc-perlman-2013-09-19
Reviewed revision 02 (document currently at 03)
Result Has Issues
Completed 2013-09-19
review-ietf-mmusic-delayed-duplication-02-secdir-lc-perlman-2013-09-19-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document is about allowing a sender of a multicast stream to advertise
that it will be sending duplicate streams offset in time, so that receivers can
receive multiple copies...so that if packets are lost they will hopefully
receive it from the later stream(s).

From a security point of view, there's no reason to complain.  However, I'm
really dubious about what this will be used for, and whether this is the best
way to solve the problem.  How does one cope with loss?  For instance...

a) request retransmissions of specific missing pieces, perhaps not from the
original source, but from a redistribution point (e.g., zillions of scalable
reliable multicast protocols that were talked about/published years ago)

b) send forward error correction so that the data can be reconstructed (e.g.,
Digital Fountain)

c) cope with glitches on your video when in rare cases, e.g., network topology
changes, some data gets lost

I'm not sure multicast is used so much anyway.  What are the applications
today?  It seems like most video is individual on-demand rather than multicast.
 And if there were some sort of multicast thing (like a sporting event), it
seems like any combination of a), b), and c) above would be preferable to
multicasting everything multiple times.

A specific comment:  In the security considerations section it says "the SDP
description needs to be integrity protected..."  Is this MUST be?  SHOULD be?

Radia