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

[Gonzalo Camarillo <[e-mail]>]

Hi Flemming,

thanks for your review. The authors of the draft have just submitted a
new revision:

http://tools.ietf.org/html/draft-ietf-dccp-udpencap-11

And the diff from revision 10:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dccp-udpencap-11.txt

Cheers,

Gonzalo

On 07/06/2012 12:43 AM, Flemming Andreasen wrote:
> 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
> 
>