Subject: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Thu, 17 Aug 2017 15:53:05 -0700

Adam Roach has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the quick answer to my DISCUSS.

I agree with the core assertion of EKR's DISCUSS: this document needs to be
aligned with JSEP. I think we're going to need a little additional work
figuring out which document needs to change where they disagree. In addition to
those areas he highlights in his DISCUSS, the following text is also in
conflict:

DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute
values, and the combination of both values identify the DTLS association."

JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as
in the offer."

[Note: this does appear to be an issue in JSEP rather than this document]

I would think the long-form title of this document should include "TLS," to
reflect that it also contains TLS-related procedures.

Section 1: "...but currently there is no way..." will not age well once this is
an RFC. Suggest "...previously, there was no way..." or somesuch.

Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a
non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate.

The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace
"SRTP-DTLS" with "DTLS-SRTP" everywhere it appears.

The last paragraph in section 5.4 starts with "NOTE" (which implementors
frequently read as non-normative) and then contains a normative statement.
Suggest removing "NOTE:"

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - SDP - Session Description Protocol
 - DTLS - Datagram Transport Layer Security
 - TLS - Transport Layer Security
 - ICE - Interactive Connectivity Establishment
 - SCTP - Stream Control Transmission Protocol
 - SRTP - Secure Realtime Transport Protocol
 - UDPTL - UDP Transport Layer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Aug 2017 09:38:28 +0000

Hi Adam,

Thanks for your review!

I see that you cleared your DISCUSS, but suggested some clarification
text. We will look into that.

Correct.

>reflect that it also contains TLS-related procedures.

The issue is that the document doesn¹t really define the O/A procedures
for TLS. It simply adds the usage of the tls-id attribute to the existing
procedures defined elsewhere.

>an RFC. Suggest "...previously, there was no way..." or somesuch.

I will modify as suggested.

>non-normative "must." I would strongly recommend moving to RFC 8174

I will change the boilerplate.

>"SRTP-DTLS" with "DTLS-SRTP" everywhere it appears.

I will modify as suggested.

>frequently read as non-normative) and then contains a normative statement.

I will remove ³NOTE:².

> - UDPTL - UDP Transport Layer

I¹ll fix that.

Thanks!

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 23 Aug 2017 13:30:10 -0500

> procedures defined elsewhere.

Right, so make that clear. I note that simply adding "and Identification 
of TLS Connections" to the end is ambiguous (since it makes it sound 
like it defines O/A for TLS), but you can fix this by reversing the 
existing title; e.g., something like: "Establishing Datagram Transport 
Layer Security (DTLS) Using the Session Description Protocol (SDP) 
Offer/Answer Mechanism and Identification of Transport Layer Security 
(TLS) Connections in SDP"

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Aug 2017 06:14:32 +0000

Hi,

>(TLS) Connections in SDP"

Works for me.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Aug 2017 12:48:05 -0500

> On Aug 23, 2017, at 1:30 PM, Adam Roach <[email-masked]> wrote:
> 
> Right, so make that clear. I note that simply adding "and Identification of TLS Connections" to the end is ambiguous (since it makes it sound like it defines O/A for TLS), but you can fix this by reversing the existing title; e.g., something like: "Establishing Datagram Transport Layer Security (DTLS) Using the Session Description Protocol (SDP) Offer/Answer Mechanism and Identification of Transport Layer Security (TLS) Connections in SDP”

Wow, that’s petty cumbersome as a title—it’s pretty much an abstract. Does it need that much detail?

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Aug 2017 12:52:38 -0500

> Wow, that’s petty cumbersome as a title—it’s pretty much an abstract. Does it need that much detail?

It's the result of taking a reasonably short title ("Establishing DLTS 
using the SDP Offer/Answer Mechanism and Identification of TLS 
Connections in SDP") and applying RFC Editor policies of acronym 
expansion to it. If you can think of some shorter way to say it, that'd 
be great -- but if I'm perusing a list of titles for something 
TLS-related and come across one that mentions only DTLS, I'd skip over 
it. The original title seems like a genuine flaw.

/a

---

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Aug 2017 13:02:41 -0500

> On Aug 24, 2017, at 12:52 PM, Adam Roach <[email-masked]> wrote:
> 
> It's the result of taking a reasonably short title ("Establishing DLTS using the SDP Offer/Answer Mechanism and Identification of TLS Connections in SDP") and applying RFC Editor policies of acronym expansion to it. If you can think of some shorter way to say it, that'd be great -- but if I'm perusing a list of titles for something TLS-related and come across one that mentions only DTLS, I'd skip over it. The original title seems like a genuine flaw.

Here’s a sacrificial proposal from the _much_ more general side:  

    “DTLS and TLS considerations in the SDP Offer/Answer Mechanism” 

… with appropriate acronym expansions of course. That may be too expansive, but we do have the abstract to narrow the focus. Some alternatives:
 
   “DTLS and TLS Session Management in the SDP Offer/Answer Mechanism” 
   “DTLS and TLS Security Association Management in the SDP Offer/Answer Mechanism” 

Ben.

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Aug 2017 13:53:03 -0500

On 8/24/17 13:02, Ben Campbell wrote:
> … with appropriate acronym expansions of course.

I have no problem with that.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Aug 2017 12:55:10 +0000

Hi,

On 24/08/17 21:53, "Adam Roach" <[email-masked]> wrote:

>>>>>>> I would think the long-form title of this document should include
>>>>>>>"TLS,"
>>>>>>> to
>>>>> Right, so make that clear. I note that simply adding "and
>>>>>Identification of TLS Connections" to the end is ambiguous (since it
>>>>>makes it sound like it defines O/A for TLS), but you can fix this by
>>>>>reversing the existing title; e.g., something like: "Establishing
>>>>>Datagram Transport Layer Security (DTLS) Using the Session
>>>>>Description Protocol (SDP) Offer/Answer Mechanism and Identification
>>>>>of Transport Layer Security (TLS) Connections in SDP”
>>>> Wow, that’s petty cumbersome as a title―it’s pretty much an abstract.
>>>>Does it need that much detail?
>>>>

“In the mechanism” sounds a little strange in my ears, so I suggest:

“SDP Offer/Answer considerations for DTLS and TLS”

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 25 Aug 2017 09:35:45 -0500

> On Aug 25, 2017, at 7:55 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> 

WFM, and even saves 2 more words :-)  

It will of course need expansions for SDP, DTLS, and TLS, but I assume you plan that.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Aug 2017 09:50:25 +0000

Hi,

PR has been updated with the new title.

Regards,

Christer