Hi Carlos, Thanks for your review! Please see inline. >Reviewer: Carlos Pignataro >Review result: Has Nits > >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. I can put each section change in a separate section. 9.2.1 Update to section 5 9.2.2 Update to section 6.6 ... Or, do you want to have the old and new text in different sections too? Personally I would like to keep the old and new text in the same section. >b. Use more explicit chunk demarkators It was been suggested to use "|". >c. Use beginning and ending markers. [BEGIN] Blah blah blah... [END] ---------- >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. Correct. I will do that in the next version. >But for example, why does NEW text here still points to RFC 4572? The reason is probably that, initially draft-4572-update did not obsolete RFC 4572 - it simply updated it. But, later it was agreed that draft-4572-update will obsolete RFC 4572, but that was not reflected in draft-dtls-sdp. So, you are correct, the new text shall point to RFC 8122. I will fix that in the next version. --------- >--->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? I will make the reference Informative. Thanks! Regards, Christer