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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 14 January 2013 09:19 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 B339E21F8587 for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2013 01:19:43 -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 UKyntghYe3LE for <mmusic@ietfa.amsl.com>; Mon, 14 Jan 2013 01:19:42 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F152121F855D for <mmusic@ietf.org>; Mon, 14 Jan 2013 01:19:41 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-7e-50f3cdac6a8c
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B7.1B.32353.CADC3F05; Mon, 14 Jan 2013 10:19:41 +0100 (CET)
Received: from [131.160.36.129] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Mon, 14 Jan 2013 10:19:40 +0100
Message-ID: <50F3CDAC.8090702@ericsson.com>
Date: Mon, 14 Jan 2013 11:19:40 +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: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
References: <50EFFC93.70406@ericsson.com> <50F3CBC6.90901@ericsson.com>
In-Reply-To: <50F3CBC6.90901@ericsson.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje7as58DDKac4bCYuvwxi8W5T3dZ HJg8liz5yeRx99YlpgCmKC6blNSczLLUIn27BK6MLQvfMxX8VanY1GvbwHhYpouRk0NCwESi r20CK4QtJnHh3nq2LkYuDiGBk4wSyxfOZ4Rw1jBK/Gq5xwZSxSugLfFy4UMWEJtFQFWiYeMr RhCbTcBCYsut+2BxUYEoifdXm5gh6gUlTs58AhYXETCVaJu1BcxmFgiQWPtzOhOILSxgI7F+ /QqweiEBd4kVndPBdnEKaElsPPyfCeI6SYlF0zqhevUkplxtYYSw5SW2v50D1astsfxZC8sE RqFZSFbPQtIyC0nLAkbmVYzsuYmZOenl5psYgaF6cMtvgx2Mm+6LHWKU5mBREucNd70QICSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoFxZoPQs7smfNlb9i5QeymceScq0XuTrNrNw+VxrbU8 /H6Tg4I25WcFaeZMvOevfbn7/9kJhY++ifyxSgpMni+ap6LNqvZzbU+sseqdyzbZ+SESl6b9 e9T2y9ZkVfy3Veu9Qvj69+8zKWNkE2ef2pV0mFm/ZPI2oT0rGms1jhR7t/UG7r4tWarEUpyR aKjFXFScCACR+d7iIwIAAA==
Cc: mmusic <mmusic@ietf.org>
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: Mon, 14 Jan 2013 09:19:45 -0000

Hi Miguel Angel,

thanks for your quick response. I am OK with all your proposals below.
When you implement the changes, please post a new revision of the draft.

Thanks,

Gonzalo

On 14/01/2013 11:11 AM, Miguel A. Garcia wrote:
> Hi Gonzalo:
> 
> Here are some inline comments. I am about to post version -17 addressing
> your comments:
> 
> 
> On 11/01/2013 12:50, 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 "-".
> 
> Ok.
> 
>>
>> 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?
> 
> The sort-of-syntax in Section 5.2.3.1 is simply an introduction to the
> three types of correlation mechanisms that can be used. So, the syntax
> is the way to introduce to Sections 5.2.3.2, 5.2.3.3, and 5.2.3.4.
> 
> But I understand your point. I suggest removing the syntax from there
> and including a pointer to Section 5.7, where the formal syntax is
> described.
> 
>>
>> 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?
> 
> This is a hard problem even to provide guidance, because the PSTN E.164
> numbers have a variable length. So, if you want to do it right, you
> should become aware of the number plan in the network you are camping.
> But this is outside the scope of the specification.
> 
> We can add a note to refer to ITU-T E.164 specification in order for
> implementations to consider what the right number of digits is.
> 
>>
>> 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?
>>
> 
> Yeap, and I found that there is an RFC specifying it (there is always an
> RFC specifying what you want :-). It is RFC 4648 and we are referring to
> the base16 (or "hex") encoding. We will change the text accordingly.
> 
> 
>> 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?
> 
> Ok, I guess we are talking of 5 to 10 digits.
> 
>>
>> 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.
> 
> ok.
> 
>>
>> 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.
> 
> ok too.
> 
>>
>> 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.
> 
> Done
> 
> 
> 
> Thanks,
> 
> 
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>