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.