Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-proto-iana-registration

From: "Ben Campbell" <[email-masked]>
Date: Thu, 14 Jan 2016 16:12:24 -0600

Hi,

Here's my AD Evaluation of draft-ietf-mmusic-proto-iana-registration. I 
have a couple of comments I'd like to resolve before last call, and a 
few editorial comments.:

Substantive (to be resolved before last call):

- (This is really editorial, but I think there's a chance for 
confusion.) The references in section 3 seem insufficient. Section 1 
lists RFCs that define most of all of the related transport protocol 
profiles. For example, [RFC4585] for TCP/RTP/AVPF and [RFC3711] for 
TCP/RTP/SAVP. That information should probably also go in section 3, 
since that's the section referenced by the IANA considerations section. 
To avoid duplication, consider moving the bits after the first paragraph 
of section 1 into the respective subsections of 3.

- The security considerations seem inadequate. Most, if not all, of the 
proto values listed here refer to some other RFC that has it's own 
security considerations. So it doesn't really seem true to say there are 
no considerations other than those in 4566.

Editorial (non-blocking):

- The abstract is long. The 2nd paragraph describes what the draft does. 
Can some or all of the first paragraph be relegated to the intro?

- 3: It would be helpful to mention that the transport protocol 
mentioned in the first paragraph goes in the <proto> field in the 
M-line.

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 18 Jan 2016 16:09:32 -0800

Hello Ben

 Thanks for the review. Please see below for the resolutions  on your
comments (marked in bold).

*- (This is really editorial, but I think there's a chance for confusion.)
The references in section 3 seem insufficient. Section 1 lists RFCs that
define most of all of the related transport protocol profiles. For example,
[RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That information
should probably also go in section 3, since that's the section referenced
by the IANA considerations section. To avoid duplication, consider moving
the bits after the first paragraph of section 1 into the respective
subsections of 3.*

[Suhas] Removed the detailed proto descriptions from Section 1 and moved
them to individual sections in Section 3.

Now the Section1 just has the following para regarding the identifiers.

"
This specification describes additional SDP transport protocol identifiers
for transporting RTP Media over TCP as defined in Section 3
<#sec.proto-identifiers>.
"

and Section 3 has been updated  to have template as below

"
3.1. <#rfc.section.3.1> TCP/RTP/AVPF Transport Realization
<#sec.tcp.rtp.avpf>

The TCP/RTP/AVPF transport describes RTP Media with RTCP-based Feedback
[RFC4585] <#RFC4585> over TCP.

It is realized as described below:

   - RTP/AVPF stream over the TCP transport is realized using the framing
   method defined in[RFC4571] <#RFC4571>.

3.2. <#rfc.section.3.2> TCP/RTP/SAVP Transport Realization
<#sec.tcp.rtp.savp>

The TCP/RTP/SAVP transport describes Secure RTP (SRTP) Media [RFC3711]
<#RFC3711> over TCP.

It is realized as described below:

   - RTP/SAVP stream over the TCP transport is realized using the framing
   method defined in[RFC4571] <#RFC4571>.

and so on for other proto identifiers

*- The security considerations seem inadequate. Most, if not all, of the
proto values listed here refer to some other RFC that has it's own security
considerations. So it doesn't really seem true to say there are no
considerations other than those in 4566.*

[Suhas] The new security considerations sections is as below
"
6. <#rfc.section.6> Security Considerations <#sec.security>

The new "proto" identifiers registered by this document in the SDP
parameters registry maintained by IANA is primarily for use by the
offer/answer model of the Session Description Protocol[RFC3264] <#RFC3264> for
the negotiation and establishment of RTP based Media over the TCP
transport. This specification doesn't introduce any additional security
considerations beyond those specified by the individual transport protocols
identified in the "proto" identifiers and those detailed in Section 7 of
[RFC4566] <#RFC4566>.
"

*- The abstract is long. The 2nd paragraph describes what the draft does.
Can some or all of the first paragraph be relegated to the intro?*
[Suhas] I have removed the first para from the abstract and moved it to the
intro section. The new abstract is :

"
Abstract <#rfc.abstract>

The Real-time Transport Protocol (RTP) specification establishes a registry
of profile names for use by higher-level control protocols, such as the
Session Description Protocol (SDP), to refer to the transport methods. This
specification describes the following new SDP transport protocol
identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF',
'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF',
'TCP/TLS/RTP/AVP', 'TCP/TLS/RTP/AVPF'
"

*- 3: It would be helpful to mention that the transport protocol mentioned
in the first paragraph goes in the <proto> field in the M-line.*

[Suhas]. I updated the section 3 intro to have the follow new text

"
The 'm=' line in SDP specifies, among other items, the transport
protocol *(identified
via the 'proto' field)* to be used for the media in the session. See the
"MediaDescriptions" section of SDP [RFC4566] <#RFC4566>for a discussion on
transport protocol identifiers.
"

Please let me know if these edits look fine and I can produce a new version
for further review.

Cheers
Suhas

On Thu, Jan 14, 2016 at 2:12 PM, Ben Campbell <[email-masked]> wrote:

> have a couple of comments I'd like to resolve before last call, and a few
> editorial comments.:
>
> - (This is really editorial, but I think there's a chance for confusion.)
> The references in section 3 seem insufficient. Section 1 lists RFCs that
> define most of all of the related transport protocol profiles. For example,
> [RFC4585] for TCP/RTP/AVPF and [RFC3711] for TCP/RTP/SAVP. That information
> should probably also go in section 3, since that's the section referenced
> by the IANA considerations section. To avoid duplication, consider moving
> the bits after the first paragraph of section 1 into the respective
> subsections of 3.
>
> proto values listed here refer to some other RFC that has it's own security
> considerations. So it doesn't really seem true to say there are no
> considerations other than those in 4566.
>
> - 3: It would be helpful to mention that the transport protocol mentioned
> in the first paragraph goes in the <proto> field in the M-line.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 25 Jan 2016 17:31:02 -0600

Thanks Suhas, those edits look good, and would resolve my concerns.

Ben.

On 18 Jan 2016, at 18:09, Suhas Nandakumar wrote:

> security
>> few
>> confusion.)
>> security
>> mentioned