Last Call Review of draft-ietf-mmusic-dtls-sdp-22
review-ietf-mmusic-dtls-sdp-22-opsdir-lc-pignataro-2017-03-24-00

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
Other Reviews Genart Last Call review of -22 by Paul Kyzivat (diff)
Secdir Last Call review of -22 by Rich Salz (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)
Review State Completed
Reviewer Carlos Pignataro
Review review-ietf-mmusic-dtls-sdp-22-opsdir-lc-pignataro-2017-03-24
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/gSXF1Bhq6EDFxAQmzBXqZX4zhVw
Reviewed rev. 22 (document currently at 32)
Review result Has Nits
Draft last updated 2017-03-24
Review completed: 2017-03-24

Review
review-ietf-mmusic-dtls-sdp-22-opsdir-lc-pignataro-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.

Like:

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

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

NEW TEXT:
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?

--->8---
NEW TEXT:

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].
--->8---

And why RFC 4572 is Normatively referenced?

Thanks,

Carlos Pignataro.