This draft may be on the right track but has open issues, described in the
review.

Even though I personally find this draft very informative and useful I
remain uncertain as a reader as of the actual purpose of this document and
what purpose it servers to publish this as an RFC.

The draft does not define any protocol or describe any requirements for a
specific protocol. Nor does is describe an implementation of any kind. The
purpose of the document seems given in the following text in section 6:

³it is hoped that this memo explains why SRTP is not mandatory as the media
security solution for RTP-based systems, and why we can expect multiple key
management solutions for systems using RTP.²

It would be great if this document, in the Introduction section could
provide some information, not only about the document content, but why this
information is desired in RFC form in comparison with other potentially
similar subjective memos about RTP security.


Some opinions seems to be lacking a clear context.
E.g: 

³Using the SRTP framework in addition to TLS is unncessary²

³IPsec security associations for other purposes, and can reuse those to
secure the RTP session [3GPP.33.210].  SRTP is, again, unnecessary in such
environments, and its use would only introduce overhead for no gain²


At the same time SRTP is said to be:
³... an application-level media security solution, encrypting the media
payload data (but not the RTP headers) to provide some degree of
confidentiality²

Generally I can think of many scenarios where you might want to deploy an
application level security solution in addition to a link or network layer
security solution. One is that an application level security solution is
providing end to end security which may be integrated with an application,
while a network layer security solution would secure also control
information.

As the draft does not tell me the context of its claims, it becomes hard to
evaluate if some context specific scenarios are relevant or not.