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 rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-11-19
Requested 2013-09-12
Draft last updated 2013-11-21
Completed reviews Genart Last Call review of -03 by Joel 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
Review review-ietf-mmusic-duplication-grouping-03-secdir-lc-roca-2013-11-21
Reviewed rev. 03 (document currently at 04)
Review result Has Issues
Review completed: 2013-11-21

Review
review-ietf-mmusic-duplication-grouping-03-secdir-lc-roca-2013-11-21

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