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