Last Call Review of draft-ietf-mmusic-dtls-sdp-22

Request Review of draft-ietf-mmusic-dtls-sdp
Requested rev. no specific revision (document currently at 32)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-04-06
Requested 2017-03-17
Authors Christer Holmberg, Roman Shpount
Draft last updated 2017-03-24
Completed reviews Genart Last Call review of -22 by Paul Kyzivat (diff)
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 (diff)
Genart Telechat review of -28 by Paul Kyzivat (diff)
Assignment Reviewer Carlos Pignataro 
State Completed
Review review-ietf-mmusic-dtls-sdp-22-opsdir-lc-pignataro-2017-03-24
Reviewed rev. 22 (document currently at 32)
Review result Has Nits
Review completed: 2017-03-24


This document is very comprehensive. Operational Considerations are adequately covered.

In reviewing this document, I did find two adjacent issues that I thought useful to comment on:

1. Clarity and Readability of Section 9

I appreciate the explicit OLD/NEW details and specifics on what is changed on the updated RFCs. I wish more documents would do this!

However, the way in which this is done is very confusing and not really optimizing clarity and readability. It is an operational issue an implementor not understanding the spec :-)

The issue, in my view, is with the labels and markers. Subsections of Section 9.2 do not follow the semantic structure of the document. Instead they are included as follows:
Update to section 5:
Which are then followed by OLD/NEW chunks. However, these chunks:
* include Section numbers and titles, 
* do not have extra indentation, and
* include only BEGIN marker but not END marker.


9.2.  Update to RFC 5763
Update to section 5:
5.  Establishing a Secure Channel

[... and then, two pages later ...]

5.  Establishing a Secure Channel

I'd suggest:
a. Using Section 9.2.1, 9.2.2, etc. for each change.
b. Use more explicit chunk demarkators
c. Use beginning and ending markers.

2. The second issue, and likely this was discussed, relates to the use of RFC 4572. A reference to RFC 4572 is Normative, and it is cited within "NEW" text (not only "OLD" text). However RFC 4572 has been Obsoleted by RFC 8122!

This is because draft-ietf-mmusic-4572-update published as RFC 8122, which should be updated. 

But for example, why does NEW text here still points to RFC 4572?


5.  Establishing a Secure Channel

   The two endpoints in the exchange present their identities as part of
   the DTLS handshake procedure using certificates. This document uses
   certificates in the same style as described in "Connection-Oriented
   Media Transport over the Transport Layer Security (TLS) Protocol in
   the Session Description Protocol (SDP)" [RFC4572].

And why RFC 4572 is Normatively referenced?


Carlos Pignataro.