Last Call Review of draft-ietf-mmusic-msrp-usage-data-channel-23

Request Review of draft-ietf-mmusic-msrp-usage-data-channel
Requested rev. no specific revision (document currently at 24)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2020-07-21
Requested 2020-07-07
Authors Jose Recio, Christer Holmberg
Draft last updated 2020-08-12
Completed reviews Genart Last Call review of -21 by Brian Carpenter (diff)
Secdir Last Call review of -22 by Alexey Melnikov (diff)
Tsvart Last Call review of -23 by Yoshifumi Nishida (diff)
Opsdir Last Call review of -22 by Al Morton (diff)
Assignment Reviewer Yoshifumi Nishida 
State Completed
Review review-ietf-mmusic-msrp-usage-data-channel-23-tsvart-lc-nishida-2020-08-12
Posted at
Reviewed rev. 23 (document currently at 24)
Review result Ready with Nits
Review completed: 2020-08-12


This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

Summary: This document is almost ready for publication, but I think it will be better to clarify the following points.

1: If the other endpoints is on a TCP connection, It seems to me that it can look downgrading the security level of the connection.
   If this is the case, do we need some guidances here?

2: 'If the non-data channel endpoint does not support MSRP CEMA, transport level interworking mode is not possible,
   it needs to act as an MSRP B2BUA.'
   -> This may sound like it falls back to B2BUA when CEMA is not available.
        But, I guess there might be a case where users don't want fallback.

3: As the doc mentions the use of B2BUA, it might be useful to refer security consideration in RFC7092 in Section 9.