On 15 Jun 2011, at 14:32, 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
Agree. These both seem good additions.
> - 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.
Makes sense.
> - 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?
It's from RFC 5762. We should add a reference.
> - I agree with your comment at the end of Section 5.5 indicating that an
> example using ICE would be beneficial.
Yep.
> - Section 7.3. There are two references pointing to Section 5.1 in the
> document, but they should actually point to Section 5.2
>
> - I think the following references should be made normative: ICE-TCP,
> RFC3264, RFC 4566, RFC5245, RFC5761
I'm happy with all of these being made normative.
Cheers,
Colin
> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
--
Colin Perkins
http://csperkins.org/
