Last Call Review of draft-ietf-mmusic-duplication-grouping-03
review-ietf-mmusic-duplication-grouping-03-secdir-lc-roca-2013-11-21-00
Request | Review of | draft-ietf-mmusic-duplication-grouping |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2013-11-19 | |
Requested | 2013-09-12 | |
Authors | Ali C. Begen , Yiqun Cai , Heidi Ou | |
I-D last updated | 2013-11-21 | |
Completed reviews |
Genart Last Call review of -03
by Joel M. Halpern
(diff)
Secdir Last Call review of -03 by Vincent Roca (diff) Opsdir Telechat review of -03 by Fred Baker (diff) |
|
Assignment | Reviewer | Vincent Roca |
State | Completed | |
Request | Last Call review on draft-ietf-mmusic-duplication-grouping by Security Area Directorate Assigned | |
Reviewed revision | 03 (document currently at 04) | |
Result | Has issues | |
Completed | 2013-11-21 |
review-ietf-mmusic-duplication-grouping-03-secdir-lc-roca-2013-11-21-00
Hello, 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. IMHO, the document is Almost ready. My main comment WRT this I-D is the following: 1- There is no reference to RFC4566 (SDP) security section! This is a pity as the security considerations are very well addressed in this RFC, much better than in the present I-D I would say. Additionally, I don't think that adding duplication grouping to SDP changes so much the situation WRT SDP security, so this is one more reason to have this reference. Otherwise: 2- The authors say that "there is a weak threat". Is the threat weak in the sense it is unlikely to happen (why?), or is it weak in the sense it will have limited consequences? In any case, I would be in favor of removing "weak" altogether. 3- Since we are now all aware of the necessity of making pervasive monitoring more complex, it could be useful to say that having some confidentiality is recommended (in addition to integrity and authentication of course). This is not discussed in RFC4566 (but it was published in 2006), so it's worth mentioning it in this I-D (no need to say much). Non security related comment: 4- The [IC2011] reference should be updated. It's published, and the volume/number are now known. Cheers, Vincent