Document: draft-ietf-sip-media-security-requirements-07.txt
Reviewer: Elwyn Davies
Review Date:  10 October 2008
IETF LC End Date: 13 October 2008
IESG Telechat date: (if known) -

Summary:
This document is almost ready for the IESG.  I have a couple of comments and queries about the reasoning in a few of the requirements.  
Meta-comment:  To a non-SIPper the problems to be solved and the requirements look very challenging!  And to think S in SIP might once have meant...
Disclaimer: Whilst the requirements appear sensible and internally consistent, I have no idea if the set is complete or really appropriate. 
The explanations in s4 are very helpful and clear for a naive reader like me. Likewise, I do not have the necessary knowledge to verify the statements in the various appendices relating to existing proposals.  
Again they look reasonable sensible.

Comments:
s5.1, Requirement R-RTP-VALID:  I think some explanation of  why '...the key
         negotiation packets MUST NOT pass the RTP validity check
         defined in Appendix A.1 of [RFC3550].' would help.  This looks like a magic incantation to me at present!

s5.1, Requirement R-NEGOTIATE:  'The media security key management protocol MUST allow a SIP
         User Agent to negotiate media security parameters for each
         individual session.'   Does this imply that the protocol MAY 
allow the SIP UA to use the same parameters for several sessiosn if it wants to? Might be wise to be explicit.. but I may not understand the situation.

s5.2, Requirement R-FIPS:  Whilst I know that the FIPS process is often cited other than in the US, this requirement appears very US centric.  
Are there other similar requirements from other countries that ought to be considered?

s5.2, Requirement R-DOS:  Whilst I know that it is probably impossible to guarantee that a given solution will not introduce some arcane DOS opportunity that no one has thought of, it seems to me that 'MUST NOT introduce any foreseeable (or, maybe, significant) new DoS vulnerabilities' would be better than SHOULD NOT, which allows for possible weaseling.

Nits:

s4.2, last line on p.9: s/ares/are/
sA.5.4, MIKEY-NULL bullet: s/computaional/computational/ idnits reports:
draft-ietf-sip-media-security-requirements-07.txt(1166): Line has weird
spacing: '...ication  along...'
Several references are now at later versions and draft-ietf-msec-mikey-applicability has been published as RFC 5197.