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 rev. | 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 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 rev. | 02 (document currently at 03) | |
| Review result | Has Issues | |
| Review completed: | 2013-09-19 |
Review
review-ietf-mmusic-delayed-duplication-02-secdir-lc-perlman-2013-09-19
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