Subject: [Gen-art] Assignments for May 20, 2010 Telechat

From: Mary Barnes <[email-masked]>
Date: Fri, 14 May 2010 12:54:45 -0500

Hi all,

Here's the link to the summary of assignments for the May 20, 2010 telechat:
http://www.softarmor.com/rai/temp-gen-art/reviewers-100520.html

With the updated spreadsheets:
http://www.softarmor.com/rai/temp-gen-art/gen-art.html
http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://www.alvestrand.no/ietf/gen/art/review-guidelines.html

Mary.

-------------------------------------------------------------------

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:
Reviewer:
Review Date:
IESG Telechat date: 20 May 2010

Summary:

Major issues:
Minor issues:
Nits/editorial comments:

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 27 May 2010 17:52:18 +0200

I am the assigned Gen-ART reviewer for
draft-ietf-avt-srtp-not-mandatory-05.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other Last Call comments you
may receive.

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.