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

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

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