Last Call Review of draft-ietf-mmusic-dtls-sdp-22
review-ietf-mmusic-dtls-sdp-22-genart-lc-kyzivat-2017-03-27-00

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.