Re: [MMUSIC] [dccp] Reviewing draft-ietf-dccp-udpencap

[Gorry Fairhurst <[e-mail]>]

See in-line on dccp-service-code.

Gorry

On Wed, 15 Jun 2011, Miguel A. Garcia wrote:

> A quick review of Section 5 of this document:
>
> - I think it is a good idea to clearly indicate which SDP attributes are 
> newly created and which ones are reused from other RFCs. I therefore 
> recommend to add the following sentences somewhere to the corresponding 
> sections:
>
> 5.3:
> RFC 4145 [RFC4145] defines the "setup" attribute whose purpose is to indcate 
> which of the end points should initiate the connection establishment. This 
> document reuses the "setup" attribute to similarly indicate which end point 
> initiates the DCCP-UDP connection establishment.
>
> 5.4:
> RFC 5245 [RFC5245] defines the "candidate" attribute whose purpose is to 
> provide one of many possible candidate addresses for communication. This 
> document reuses the "candidate" attribute to indicate native or encapsulated 
> candidate addresses
>
>
[After re-reading this I note that this section speaks of "native" DCCP
whereas there was an earlier suggestion that this should be called 
"DCCP-STD", Colin and I should ensure this is consistent in the next 
revision.]

> - In 5.2 last paragraph, I am missing some normative statements, for example:
>
> If RTCP is multiplexed with RTP, endpoints MUST encode the DCCP port used for 
> RTCP in the "rtcp" attribute specified in RFC 3605 [RFC3605]. An SDP offerer 
> MAY indicate its willingnes to multiplex RTP and RTCP onto a single DCCP port 
> by adding an "rtcp-mux" attribute as specified in RFC 5761 [RFC5761]. If the 
> answer also includes the "rtcp-mux" attribute (as per RFC 5761 [RFC5761]), 
> then RTP and RTCP are multiplexed onto a single DCCP port, otherwise separate 
> DCCP ports are used for RTP and RTCP.  In each case, only a single UDP port 
> is used for the DCCP-UDP encapsulation.
>
> - I didn't find any description of the "dccp-service-code". However, it is 
> written in the examples in Section 5.5. Is this a leftover from a previous 
> version of the document?
>
I suggest a couple of lines to be clear to anyone composing  SDP:

RFC 5762 [RFC5762] defines the "dccp-service-code" attribute whose purpose 
is to identify the intended service/application to process a DCCP 
connection request [RFC5595]. The "dccp-service-code" attribute is the 
same for both DCCP-STD and DCCP-UDP encapsulations.

> - I agree with your comment at the end of Section 5.5 indicating that an 
> example using ICE would be beneficial.
>

So, as soon as we have this, I think we can then finalise the text!

> - Section 7.3. There are two references pointing to Section 5.1 in the 
> document, but they should actually point to Section 5.2
>
Noted, will fix.

> - I think the following references should be made normative: ICE-TCP, 
> RFC3264, RFC 4566, RFC5245, RFC5761
>
Seems OK to me, I'll see if Colin agrees.

> BR,
>
>       Miguel
>
>
> On 15/06/2011 9:42, Pasi Sarolahti wrote:
>> Hi,
>> 
>> In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram 
>> Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal 
>> (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC 
>> (especially Section 5), and it was presented in the MMUSIC meeting in last 
>> IETF. The authors have modified the text based on the input received, and 
>> we are now looking for volunteer(s) from MMUSIC to review whether the new 
>> text (mostly in Section 5) looks ok, before moving forward with the draft.
>> 
>> The draft can be found at 
>> http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08
>> 
>> - Pasi
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>
> -- 
> Miguel A. Garcia
> [phone]
> Ericsson Spain
>