Re: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 11 January 2013 11:52 UTC

Return-Path: <gonzalo.camarillo@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 3CC5921F86A2 for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 03:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 CX87OoGpmeSt for <mmusic@ietfa.amsl.com>; Fri, 11 Jan 2013 03:52:18 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 99EBB21F866D for <mmusic@ietf.org>; Fri, 11 Jan 2013 03:52:16 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-4f-50effceeda21
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CA.68.10459.EECFFE05; Fri, 11 Jan 2013 12:52:15 +0100 (CET)
Received: from [131.160.36.91] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 11 Jan 2013 12:52:14 +0100
Message-ID: <50EFFCEE.1080601@ericsson.com>
Date: Fri, 11 Jan 2013 13:52:14 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
References: <50EFFC93.70406@ericsson.com>
In-Reply-To: <50EFFC93.70406@ericsson.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje77P+8DDM4/5bKYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4MmYteMResEayYsXRE+wNjKeEuxg5OSQETCTe3+5nhbDFJC7c W8/WxcjFISRwklHi9e4DUM5qRolXP/4zg1TxCmhLrN5/hgnEZhFQlZh29wsbiM0mYCGx5dZ9 FhBbVCBK4v3VJqh6QYmTM5+AxUUEZCT2btoMFhcWsJFYv34FkM0BtEBTYvaaApAwp4CWxPkT k9khDpKUWDStE6yVWUBPYsrVFkYIW15i+9s5YGOEgM5Z/qyFZQKj4Cwk22YhaZmFpGUBI/Mq RvbcxMyc9HLDTYzA8Du45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwOhhxrdRgSf9vUxR5nO3jX0z25/MU9r/3mJXzeQnx4qkn+cuLw0xv2CbmqD2wuii YiaLzdXvjxrTbvd/Dra4tfLqm0lbmJNk5P51CzrPWuT7cXla4AbOD7blhyTPCHvmazzatNHc xfenoGXSpBMlRw9Nnnj/v4OVgPpXhj1XLj3kSZ3v+dPrYY8SS3FGoqEWc1FxIgBOvKbBDQIA AA==
Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-sdp-cs-16
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: Fri, 11 Jan 2013 11:52:20 -0000

Sorry for the duplication. I had an email problem when sending the email
below and it seems to have made it to the list twice.

Gonzalo

On 11/01/2013 1:50 PM, Gonzalo Camarillo wrote:
> Hi,
> 
> I just got a publication request for the following draft:
> 
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-16
> 
> Please, find below my AD review.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> draft-ietf-mmusic-sdp-cs-16:
> 
> Page 10: remove the indentation of the following paragraph. Indented
> paragraphs are typically used to provide clarifications while this one
> contains normative language:
> 
>       Note that <addrtype> and/or <connection-address> MUST NOT be
>       omitted when unknown since this would violate basic syntax of SDP
>       [RFC4566].  In such cases, they MUST be set to a "-".
> 
> Section 5.2.3.1 provides a "format" for the cs-correlation attribute.
> However, its ABNF formal syntax is in Section 5.7. So, why does Section
> 5.2.3.1 also contain a syntax for the attribute... and what type of
> syntax is that?
> 
> Page 14: the text says:
> 
>       To mitigate this problem implementations
>       should consider only some of the rightmost digits from the E.164
> 
> Can we provide a more concrete advice (or at least some discussion) on
> the number of digits to consider?
> 
> Page 15: we define how to encode a binary value in hexadecimal format
> and represent it as a two-digit ASCII value. Can we point to an existing
> specification that defines how to do that instead of specifying it inline?
> 
> Page 17: the text says:
> 
>       Implementations are advised to select a number of DTMF digits that
>       provide enough assurance that the call is related, but on the
>       other hand do not prolong the bearer setup time unnecessarily.
> 
> Can we provide a more concrete recommendation?
> 
> Page 17: Section 5.2.3.4 specifies what to do when the correlation
> fails. However, that is described in general in Section 5.3.3. Why don't
> we move all the statements about how to decide whether the sessions are
> correlated to Section 5.3.3? Now, the following statement contradicts
> what Section 5.3.3 says, for example:
> 
>    the passive side
>    SHOULD treat the circuit-switched bearer as not correlated to the
>    ongoing session.
> 
> The indented text right after the statement above talks about
> suppressing alerting. Such a supression is applicable to any session,
> not only those that are correlated using DTMF tones. So, we could also
> move that discussion to Section 5.3.3.
> 
> Section 5.5: rephrase the following sentence (possibly splitting it into
> more than one sentence) so that it is clearer:
> 
>       Note that this may result in the recipient of the initial Offer in
>       rejecting the Offer if the recipient of the Offer is not aware of
>       its own E.164 number, and thus concluding that it will not be
>       possible to establish a circuit-switched bearer since neither
>       party is aware of their E.164 number.
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 
>