Subject: Re: Review of draft-ietf-mmusic-dtls-sdp-22

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Mar 2017 16:00:52 +0000

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 30 Mar 2017 16:13:35 +0000

Hi, Christer,

> On Mar 28, 2017, at 12:00 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Carlos,
> 

Anytime — thanks for the follow-up!

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

I agree. Having a section for each change chunk (OLD/NEW) seems most clean and clear.

>> c. Use beginning and ending markers.

Thank you — any format that you feel will add clarity. Right now it was a bit challenging to parse.

> Correct. I will do that in the next version.

Ack. Thanks.

> So, you are correct, the new text shall point to RFC 8122. I will fix that in the next version.

Perfect.

> I will make the reference Informative.

Looks good — thanks again,

— Carlos.