[MMUSIC] SDP Directorate: Review of draft-ietf-dccp-udpencap-10

Flemming Andreasen <fandreas@cisco.com> Wed, 06 June 2012 21:43 UTC

Message-ID: <4FCFCF0A.6010607@cisco.com>
Date: Wed, 06 Jun 2012 17:43:38 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: draft-ietf-dccp-udpencap@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------020101060202030701040005"
Cc: mmusic <mmusic@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-dccp-udpencap-10
Precedence: list

Hi

I am the assigned SDP directorate reviewer for draft-ietf-dccp-udpencap-10

For background on the SDP directorate, please see the FAQ at 
<http://www.ietf.org/iesg/directorate/sdp.html>.

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.


Summary:
--------
There are two minor technical issues with the current draft which should 
be discussed further.

There are also a few minor editorial issues, which can be corrected as 
part of the publication process.



New SDP Information Elements:
---------------------------
The draft defines a new "a=dccp-port" attribute



Technical:
---------
1) Section 5.2 states:
<quote>
    If the "a=rtcp:" attribute [RFC3605] is used, then the signalled 
port is the DCCP port used for RTCP.
</quote
I think this warrants further discussion. How will this work if 
non-consecutive ports are to be used for DCCP-UDP itself and how will 
this work if a middlebox looks at the "a=rtcp" attribute and assumes the 
currently defined behavior in RFC 3605, which would effectively provide 
it with the port information for the (UDP native) RTCP stream today ?


2) Section 5.4 discusses how to negotiate DCCP-UDP versus native DCCP 
(DCCP-STD) and in particular considers only the use of ICE for this 
(with the details of the encoding "left for future study"). While this 
may be appropriate for the basic use of DCCP-UDP versus DCCP-STD, it is 
arguably not appropriate when it comes to negotiating different RTP 
profiles within each of these (which are defined in this draft). SDP 
Capability Negotiation would be more suitable for this, as described in 
RFC 5939 Section 3.7. At a minimum, a reference to that effect and those 
considerations should be provided.


3) Section 3.8, 4th paragraph:
s/a DCCP-UDP server must therefore/a DCCP-UDP MUST therefore/ ??
                                               ^^^^


Editorial:
--------
Various instances of repeat words and a few spelling errors that should 
be caught by a spell-checker.

Also:
- Section 5.1, first paragraph:
s/(from [RFC4566]:/(from [RFC4566]):/
                                   ^
- Section 5.4, second paragraph
s/DCCPx/DCCP/

- Section 6, last paragraph:
s/A firewall than/A firewall that/
                                 ^

- ICE-TCP is now RFC 6544


Thanks

-- Flemming

[MMUSIC] SDP Directorate: Review of draft-ietf-dc… Flemming Andreasen
Re: [MMUSIC] SDP Directorate: Review of draft-iet… Gonzalo Camarillo