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

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 11 Jan 2013 13:50:43 +0200

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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 11 Jan 2013 13:52:14 +0200

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:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 14 Jan 2013 10:11:34 +0100

Hi Gonzalo:

Here are some inline comments. I am about to post version -17 addressing 
your comments:

>        [RFC4566].  In such cases, they MUST be set to a "-".

Ok.

> 5.2.3.1 also contain a syntax for the attribute... and what type of

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.

> 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.

> 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.

> Can we provide a more concrete recommendation?

Ok, I guess we are talking of 5 to 10 digits.

>     SHOULD treat the circuit-switched bearer as not correlated to the

ok.

> move that discussion to Section 5.3.3.

ok too.

>        party is aware of their E.164 number.

Done

Thanks,

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 14 Jan 2013 11:19:40 +0200

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:
> 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:
>>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 14 Jan 2013 10:20:31 +0100

I have just submitted version -17.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain