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

Request Review of draft-ietf-mmusic-dtls-sdp
Requested rev. no specific revision (document currently at 28)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-04-06
Requested 2017-03-17
Other Reviews Secdir Last Call review of -22 by Rich Salz (diff)
Opsdir Last Call review of -22 by Carlos Pignataro (diff)
Genart Last Call review of -26 by Paul Kyzivat (diff)
Genart Telechat review of -27 by Paul Kyzivat (diff)
Secdir Telechat review of -28 by Rich Salz
Genart Telechat review of -28 by Paul Kyzivat
Review State Completed
Reviewer Paul Kyzivat
Review review-ietf-mmusic-dtls-sdp-22-genart-lc-kyzivat-2017-03-27
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/fWkXOIi2-7KD4Z0oyJm-MtVMG9o
Reviewed rev. 22 (document currently at 28)
Review result Ready with Nits
Last updated 2017-03-27

Review
review-ietf-mmusic-dtls-sdp-22-genart-lc-kyzivat-2017-03-27

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.