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

["Ben Campbell" <[e-mail]>]

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

Ben.

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

> Hello Ben
>
> Thanks for the review. Please see below for the resolutions  on your
> comments (marked in bold).
>
>
> 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.*
>
> [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>.
> "
>
> 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?*
> [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 <[e-mail]> wrote:
>
>> 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.
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic