[apps-discuss] APPSDIR review of draft-ietf-straw-b2bua-dtls-srtp-08.txt

["Vijay K. Gurbani" <[e-mail]>]

I have been selected as the Applications Area Directorate early
reviewer for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-straw-b2bua-dtls-srtp-08.txt
Title: DTLS-SRTP Handling in Session Initiation Protocol (SIP)
        Back-to-Back User Agents (B2BUAs)
Reviewer: Vijay K. Gurbani
Review Date: 2015-11-16
IETF Last Call Date: 2015-11-17
IESG Telechat Date: 2015-12-03

Summary: This draft has minor issues, and is ready for publication as
a Proposed Standard once these issues are resolved.

I will also (strongly) suggest that the editors go over the draft for
grammatical touches to eliminate the sort of issues present in the Nits
section.  This will make the draft more readable and provide it the
gravity it needs for a standards track document.

Major: 0
Minor: 3
Nits: Many

Minor:

- S3.1.1, second to last paragraph (beginning with "[RFC4474] provides
  ... the signature."): Isn't this only true if the originating UAC
  used rfc4474 and inserted the appropriate headers.  Or is the
  assumption that rfc4474 is always used, and therefore, a media relay
  B2BUA must be careful and not modify the fingerprints?

- S3.1.2, first paragraph: "The identity integrity protection
  procedures described in Security Considerations section..."

  Described in the Security Consideration section of which document?
  The document under review or some other one (rfc7092)?

- S3.1.2.2: I am not sure what your takeaway is at the end of this
  section.  You seem to be making the case that a B2BUA cannot
  modify the RTP headers and RTCP packets.  But then you go on and
  say that this can be mitigated by using different keys, and that
  with "such an approach" (aside: define "such an approach"), the
  B2BUA is not aware of the keys used to decrypt the media payload.
  Well, the B2BUA is never aware of such keys, since they are
  negotiated end-to-end (over the B2BUA), so I am at a loss to see
  what is the point of this section.

Nits:

- Abstract: s/media plane, rather than/media plane rather than

- Abstract: s/This document describes the behavior such B2BUAs can
   adhere to/This document describes the behaviour of such B2BUAs/

- S1.1: s/The fingerprint, identifies/The fingerprint identifies

- S3.1.2:
  s/There are two types of media-aware relay/There are two types of
  media-aware relays/

- S3.1.2.1: (For readability)
  s/This kind of media aware relay/A RTP/RTCP aware media relay/

- S4: s/B2BUA replaces the Bob's/B2BUA replaces Bob's/

  (If you want to retain "the", perhaps you may consider renaming
  Bob to Donald!  Sorry, bad joke, I know.)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq