I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mmusic-dtls-sdp-22 Reviewer: Paul Kyzivat Review Date: 2017-03-27 IETF LC End Date: 2017-04-06 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has some minor issues and nits that should be fixed before publication. (I reviewed this previously as part of LC and had no comments. After being asked to do a Gen-Art review I went through it more carefully. I surprised myself by finding a few thing, though nothing major. This confirms my feeling that I can *always* find *something* to improve in a draft.) Issues: Major: 0 Minor: 1 Nits: 3 (1) Nit: Regarding the following in section 5.1: When an offerer or answerer indicates that it wants to establish a new DTLS association, it needs to make sure that media packets in the existing DTLS association and new DTLS association can be de- multiplexed. This text presumes there is an existing association. To explicitly cover the case where there is not, I suggest the following: When an offerer or answerer indicates that it wants to establish a new DTLS association to replace an existing association, it needs to ensure that media packets in the existing DTLS association and new DTLS association can be de-multiplexed. Later in the section there is a language error is the following: The certificate received during the DTLS handshake MUST match a certificate fingerprints received in SDP 'fingerprint' attributes according to the procedures defined in [I-D.ietf-mmusic-4572-update]. s/match a/match the/ OR s/certificate fingerprints/certificate fingerprint/ (2) Nit: In Section 5.4 there is again a presumption of an existing association in the following: If the answer does not establish a new DTLS association, the offerer will continue using the previously established DTLS association. To fix, I suggest: If the offer indicated a desire to reuse an existing DTLS association and the answer does not request establishment of a new DTLS association, the offerer will continue using the previously established DTLS association. (3) Minor: I concur with the comments in the ops-dir review by Carlos Pignataro regarding the formatting of section 9. He didn't suggest a fix. Perhaps some special marker (e.g. "|" or "<" and ">") can be placed in every line to indicate it is test from or for another document - either at the beginning or end of every line. (4) Nit: In Section 9: The following text is repeated multiple times: [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] It would be sufficient and less distracting to the user to simply state this once for the entire document.