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

Hi Gorry:

Your suggestions look ok to me.

BR,

        Miguel

On 16/06/2011 9:42, Gorry Fairhurst wrote:
>
> 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
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> --
>> Miguel A. Garcia
>> +34-91-339-3608
>> Ericsson Spain
>>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain