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

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Wed, 15 June 2011 13:32 UTC

Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E8011E812F; Wed, 15 Jun 2011 06:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.486
X-Spam-Level:
X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfcoTlGdI8af; Wed, 15 Jun 2011 06:32:38 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AF82611E8126; Wed, 15 Jun 2011 06:32:37 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-87-4df8b4745c08
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.BB.20773.474B8FD4; Wed, 15 Jun 2011 15:32:36 +0200 (CEST)
Received: from [159.107.24.230] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 15 Jun 2011 15:32:35 +0200
Message-ID: <4DF8B472.9090602@ericsson.com>
Date: Wed, 15 Jun 2011 15:32:34 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Pasi Sarolahti <pasi.sarolahti@iki.fi>
References: <B405CA2E-9E6C-4712-898E-0C0D041B856A@iki.fi>
In-Reply-To: <B405CA2E-9E6C-4712-898E-0C0D041B856A@iki.fi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, DCCP WG <dccp@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Colin Perkins <csp@csperkins.org>
Subject: Re: [MMUSIC] Reviewing draft-ietf-dccp-udpencap
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 13:32:39 -0000

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


- 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 agree with your comment at the end of Section 5.5 indicating that an 
example using ICE would be beneficial.

- 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

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