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

["Miguel A. Garcia" <[e-mail]>]

I have just submitted version -17.

/Miguel

On 14/01/2013 10:19, Gonzalo Camarillo wrote:
> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain