Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Mar 2011 11:13:02 -0400

I have a couple of comments on this draft:

There is still work to do to extend the o/a rules to handle '-' as a 
media format. Specifically, if the offer contains '-', what may the 
answer contain? And if the offer does not contain '-', may the answer?

When using uuie correlation, the uuie-value is defined as 
1*32(ALPHA/DIGIT). The PSTN user-user data starts with a discriminator 
byte that can be any one of 256 values. The draft doesn't mention if the 
uuie-value contains the discriminator byte, or if that byte is assumed 
to have some well known value. If it is to include the discriminator 
byte, then some important discriminator byte values are neither alpha 
nor digit. IMO the draft at least needs to explain what is intended.

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 25 Mar 2011 12:28:24 +0100

Hi Paul,

Thanks for your comments. See inline answers.

> answer contain? And if the offer does not contain '-', may the answer?

For sure, I agree. I think the information must be hidden or implicitly 
described, but this should be explicitly specified. At the moment the 
draft has O/A procedures for negotiating the correlation mechanism 
(Section 5.3). I think we should just have a more generic O/A procedures 
that discuss the whole draft, not only the correlation mechanism.

> nor digit. IMO the draft at least needs to explain what is intended.

Problem acknowledged. We need to take a look at it and provide a solution.

BR,

      Miguel

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

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 09:24:23 +0000

Hello,
These are pretty much the only open issues we know of for this document. If others have any concerns, it would be great if you could post them on the list before Friday.

Thanks
Simo

> -----Original Message-----
> From: ext Miguel A. Garcia [mailto:[email-masked]]
> Sent: 25 March, 2011 13:28
> To: Paul Kyzivat
> Cc: Veikkolainen Simo (Nokia-MS/Helsinki); IETF MMUSIC WG
> Subject: Re: draft-ietf-mmusic-sdp-cs-06
> 
> Hi Paul,
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 29 Mar 2011 23:59:24 +0200

Hi Simo and Miguel

I have taken a closer look at the document and have some comments:

Section 5.2.1
- How are dynamic payload types handled ?
- How will "-" work with offer/answer (as Paul noted as well)

Section 5.2.3
- s/should not/MUST NOT

Section 5.2.3.1
- What's the specification policy for providing new correlation 
mechanisms and do we need an IANA registry ?
- Informal grammer here suggests you can specify only one of the 
mechanisms. It is claried later that multiple can be specified 
(confusing here)

Section 5.2.3.2 (and other places)
- Why not simply require the E.164 numbers always be specified in their 
full International form (i.e. with country code). While that makes the 
"+" redundant, it's still good to include it per E.164/E.123
- The "callerid" subfield is specified as being that of the party 
inserting it. That raises some security concerns that need to be 
discussed. It would also seem to prevent use of the mechanism with 3PCC, 
which I don't believe is intended.

Section 5.3
- As Paul noted, the O/A section overall needs to be expanded to 
describe the entire Offer generation, Answer generation, Offer 
processing of initial answer, and Modifying the Session (one section for 
each ala RFC 3264 preferably). The "setup", "connection", "c=", and "m=" 
lines, etc all need to be described
- Lots of SHOULDs that seem like they should be MUSTs. If keeping them 
as SHOULDs, then we should be clear on why that is (including in the 
document).
- I am confused on how the cs-correlation mechanism works. I would have 
thought the "calling" (active) party would send correlation info to the 
called (passive) party, but the O/A section seems to suggest that the 
calling (active) party gets the called (passive) party's correlation 
info and sends that to the called (passive) party somehow (spoofed 
caller-id ?). Did I misread this ?

Section 5.5
- Would suggest making "+" mandatory in all telephone numbers and stick 
to International E.164 format.
- Should restrict caller-id-value to 15 digits I believe.

Section 6
- Example should be complete and show the answer SDP and resulting PSTN 
exchange (correlation part). The correlation info text seems counter to 
what the O/A section says, but again, I'm confused on the text in this 
area in general.

Section 7
- Should move IANA Considerations to after Security Considerations

Section 8
- Additional security considerations include risks associating with 
using unverified information as caller-id. More importantly, you are 
introducing a mechanism that causes your peer to initiate a call to a 
phone number of your choosing, and the security risks associated with 
that needs to be called out.

Thanks

-- Flemming

On 3/28/11 11:24 AM, [email-masked] wrote:
>
> Hello,
> These are pretty much the only open issues we know of for this 
> document. If others have any concerns, it would be great if you could 
> post them on the list before Friday.
>
> Thanks
> Simo
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 16:04:21 +0000

Hi Flemming, and thank you again for your review.

See below.

From: ext Flemming Andreasen [mailto:[email-masked]]
Sent: 30 March, 2011 00:59
To: Veikkolainen Simo (Nokia-MS/Helsinki)
Cc: [email-masked]; Paul Kyzivat (pkyzivat); Flemming Andreasen
Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-cs-06

Hi Simo and Miguel

Section 5.2.1

[SV] I think we need to think of the media types (including the "-" from a broader perspective. In most cases, it is enough to just exchange the E.164 numbers without any media related information.

Section 5.2.3
- s/should not/MUST NOT

Section 5.2.3.1
- What's the specification policy for providing new correlation mechanisms and do we need an IANA registry ?
- Informal grammer here suggests you can specify only one of the mechanisms. It is claried later that multiple can be specified (confusing here)

[SV] We need to explicitly say what the mechanism for providing new correlation mechanisms will be. IANA registration is definitely one option, even though the current draft does not propose to register the correlation mechanisms at IANA.

[SV] Multiple mechanisms are allowed. We need to change the information grammar.

Section 5.2.3.2 (and other places)
- Why not simply require the E.164 numbers always be specified in their full International form (i.e. with country code). While that makes the "+" redundant, it's still good to include it per E.164/E.123

[SV] That could be done, if the endpoints just are always aware of their international E.164 representation.

- The "callerid" subfield is specified as being that of the party inserting it. That raises some security concerns that need to be discussed. It would also seem to prevent use of the mechanism with 3PCC, which I don't believe is intended.

[SV] We need to address this in the security considerations section.

Section 5.3
- As Paul noted, the O/A section overall needs to be expanded to describe the entire Offer generation, Answer generation, Offer processing of initial answer, and Modifying the Session (one section for each ala RFC 3264 preferably). The "setup", "connection", "c=", and "m=" lines, etc all need to be described

[SV] Right, this is what we intend to do.

- Lots of SHOULDs that seem like they should be MUSTs. If keeping them as SHOULDs, then we should be clear on why that is (including in the document).

[SV] Ok, we'll go these through.

- I am confused on how the cs-correlation mechanism works. I would have thought the "calling" (active) party would send correlation info to the called (passive) party, but the O/A section seems to suggest that the calling (active) party gets the called (passive) party's correlation info and sends that to the called (passive) party somehow (spoofed caller-id ?). Did I misread this ?

[SV] Cs-correlation is the name of the attribute carrying the actual correlation mechanisms used. The relationship between the O/A and active/passive party is a bit complicated and requires probably some clarification. In the case of caller-id correlation mechanism, for example, the calling (active) party needs to know the E.164 number of the called (passive) party. Therefore, the called party needs to return the E.164 number in the Answer (typically).

Section 5.5
- Would suggest making "+" mandatory in all telephone numbers and stick to International E.164 format.
- Should restrict caller-id-value to 15 digits I believe.

[SV] Ok.

Section 6
- Example should be complete and show the answer SDP and resulting PSTN exchange (correlation part). The correlation info text seems counter to what the O/A section says, but again, I'm confused on the text in this area in general.

[SV] We'll need to clarify this.

Section 7

[SV] Ok.

Section 8
- Additional security considerations include risks associating with using unverified information as caller-id. More importantly, you are introducing a mechanism that causes your peer to initiate a call to a phone number of your choosing, and the security risks associated with that needs to be called out.

[SV] Ok, will expand the security considerations section on these.

Thanks
Simo

Thanks

-- Flemming

On 3/28/11 11:24 AM, [email-masked]<mailto:[email-masked]> wrote:

Hello,

Thanks
Simo

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic