Subject: [stir] comments on draft-ietf-stir-problem-statement-00

From: Andrew Allen <[email-masked]>
Date: Thu, 24 Oct 2013 16:02:51 +0000

Some comments on draft-ietf-stir-problem-statement-00. I only just joined the list so apologies if I am duplicating any comments already given.
General comment
could we preface the references in the text with the RFC (or other document identifier) [1} in isolation makes the document hard to read.

Section 5.3

Due to its narrow scope of applicability, and the details of its implementation, VIPR has some significant limitations.  The most salient for the purposes of this document is that it only has bearing on repeated communications between entities: it has solution to the classic "robocall" problem, where the target typically receives a call from a number that has never called before.

Shouldn't this be it has NO solution to the classic "robocall" problem"?

Section 6.1

I think it is problematic to use as an example the Apple proprietary iMessage service which I believe is restricted to just the iOS platform (and Macs) and which does not allow "iPhone users to  send SMS messages to one another over the internet" (SMS is a specific  text only messaging service).  I think we should not reference a single company's proprietary product as there are many instant messaging applications/services out there for smartphones many of which now support multiple smartphone OS platforms (including also now my own employers BlackBerry Messaging Service) and which basically share similar characteristics in terms of out of band communications and centralized trusted databases as iMessage.  I would think that a multiple platform supporting messaging service is likely to be much more useful as  the basis for a solution than a system that is restricted to single vendor's platform.

I think this text should be generalized to talk about mobile instant messaging services in the abstract and not describe a single vendors product offering. Potentially a plurality of instant messaging services from multiple vendors could form a basis for a general solution if instant messaging ends up being part of the solution.

Another issue to consider (and it's not just relevant for the  use of instant messaging) is the use of SIM roaming or "plastic roaming" where users who are travelling use either a SIM from pool of company provided local SIM cards or purchase a local prepaid SIM card in order to eliminate roaming charges. This means that the E.164 number of the user has changed but potentially the identity used by the instant messaging service remains the same as many mobile IM services identities are independent of the E.164 number being instead tied to email addresses or device identities. In many cases the smartphone doesn't even know its E.164 number - it does with IMS though.

Section 6.5

Due to roaming and countless other factors, calls on the PSTN may emerge from administrative domains that have no relationship with the number assignee

I am not convinced that roaming (at least in the traditional sense of cellular roaming - and this will continue to be the case with IMS roaming) means that calls will emerge from administrative domains that have no relationship with the number assignee. In cellular roaming there is a very close relationship between the roamed  to network and there are trust domains between them and authentication of the mobile involving cooperation between the home network that is the number assignee and the roamed to network. If roaming here means something else then please clarify.

Section 7

Accommodating current practices:  Must allow number portability among carriers and must support legitimate usage of number spoofing(doctor's office and call centers)

I think the text in parenthesis should be prepended with e.g.

Minimal payload overhead:  Must lead to minimal expansion of SIP headers fields to avoid fragmentation in deployments that use UDP.

Is this really a MUST strength requirement? Whatever solution we come up with that requires enhancement to SIP requires some enhancement. TCP is always available to use if message sizes become too large and since the deployed systems will need to be enhanced they can be (even should be) enhanced to support TCP. I think in many cases SIP and SDP has already grown to such an extent (ICE candidates, preconditions, SDP cap neg attributes, increasing number of codecs and media lines etc...) that we are already at the point where we are perilously close to or already over the 1300 byte recommendation in many scenarios.  Any size increase at all may break the camel's back on the UDP fragmentation issue. I think at best this is guidance that message size is a factor to consider in evaluating a solution not an overriding requirement

Andrew
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 25 Oct 2013 13:28:29 -0400

In line.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Allen
Sent: Thursday, October 24, 2013 12:03 PM
To: [email-masked]
Subject: [stir] comments on draft-ietf-stir-problem-statement-00

Some comments on draft-ietf-stir-problem-statement-00. I only just joined
the list so apologies if I am duplicating any comments already given.

General comment 

could we preface the references in the text with the RFC (or other document
identifier) [1} in isolation makes the document hard to read.

Section 5.3

Due to its narrow scope of applicability, and the details of its
implementation, VIPR has some significant limitations.  The most salient for
the purposes of this document is that it only has bearing on repeated
communications between entities: it has solution to the classic "robocall"
problem, where the target typically receives a call from a number that has
never called before.  

 

[RS> ]  +1  of course I'd argue that VIPR is no solution to anything.
Personally I'd prefer any reference to VIPR should be eliminated since it
has proven non deployable and generally useless. 

Section 6.1 

I think it is problematic to use as an example the Apple proprietary
iMessage service which I believe is restricted to just the iOS platform (and
Macs) and which does not allow "iPhone users to  send SMS messages to one
another over the internet" (SMS is a specific  text only messaging service).
I think we should not reference a single company's proprietary product as
there are many instant messaging applications/services out there for
smartphones many of which now support multiple smartphone OS platforms
(including also now my own employers BlackBerry Messaging Service) and which
basically share similar characteristics in terms of out of band
communications and centralized trusted databases as iMessage.  I would think
that a multiple platform supporting messaging service is likely to be much
more useful as  the basis for a solution than a system that is restricted to
single vendor's platform.

[RS> ] Yes thank you iMessage is not an existence proof. 

I think this text should be generalized to talk about mobile instant
messaging services in the abstract and not describe a single vendors product
offering. Potentially a plurality of instant messaging services from
multiple vendors could form a basis for a general solution if instant
messaging ends up being part of the solution.

Another issue to consider (and it's not just relevant for the  use of
instant messaging) is the use of SIM roaming or "plastic roaming" where
users who are travelling use either a SIM from pool of company provided
local SIM cards or purchase a local prepaid SIM card in order to eliminate
roaming charges. This means that the E.164 number of the user has changed
but potentially the identity used by the instant messaging service remains
the same as many mobile IM services identities are independent of the E.164
number being instead tied to email addresses or device identities. In many
cases the smartphone doesn't even know its E.164 number - it does with IMS
though.

Section 6.5

Due to roaming and countless other factors, calls on the PSTN may emerge
from administrative domains that have no relationship with the number
assignee

I am not convinced that roaming (at least in the traditional sense of
cellular roaming - and this will continue to be the case with IMS roaming)
means that calls will emerge from administrative domains that have no
relationship with the number assignee. In cellular roaming there is a very
close relationship between the roamed  to network and there are trust
domains between them and authentication of the mobile involving cooperation
between the home network that is the number assignee and the roamed to
network. If roaming here means something else then please clarify.

Section 7

Accommodating current practices:  Must allow number portability among
carriers and must support legitimate usage of number spoofing(doctor's
office and call centers)
 
I think the text in parenthesis should be prepended with e.g.
[RS> ]  I dislike calling out examples of "legitimate" call spoofing. That
is essentially a national regulatory matter of what is and is not
acceptable. 

Minimal payload overhead:  Must lead to minimal expansion of SIP headers
fields to avoid fragmentation in deployments that use UDP.

Is this really a MUST strength requirement? Whatever solution we come up
with that requires enhancement to SIP requires some enhancement. TCP is
always available to use if message sizes become too large and since the
deployed systems will need to be enhanced they can be (even should be)
enhanced to support TCP. I think in many cases SIP and SDP has already grown
to such an extent (ICE candidates, preconditions, SDP cap neg attributes,
increasing number of codecs and media lines etc.) that we are already at the
point where we are perilously close to or already over the 1300 byte
recommendation in many scenarios.  Any size increase at all may break the
camel's back on the UDP fragmentation issue. I think at best this is
guidance that message size is a factor to consider in evaluating a solution
not an overriding requirement

[RS> ] Yes thank you ..The SIP headers are already out of control suggesting
MUST is absurd.  

Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.

---

From: Brian Rosen <[email-masked]>
Date: Fri, 25 Oct 2013 15:42:57 -0400

Inline
On Oct 24, 2013, at 12:02 PM, Andrew Allen <[email-masked]> wrote:

> Shouldn’t this be it has NO solution to the classic “robocall” problem”?
>  
> Section 6.1
>  
> I think it is problematic to use as an example the Apple proprietary iMessage service which I believe is restricted to just the iOS platform (and Macs) and which does not allow “iPhone users to  send SMS messages to one another over the internet” (SMS is a specific  text only messaging service).  I think we should not reference a single company’s proprietary product as there are many instant messaging applications/services out there for smartphones many of which now support multiple smartphone OS platforms (including also now my own employers BlackBerry Messaging Service) and which basically share similar characteristics in terms of out of band communications and centralized trusted databases as iMessage.  I would think that a multiple platform supporting messaging service is likely to be much more useful as  the basis for a solution than a system that is restricted to single vendor’s platform.
>  
I disagree.  First of all, it’s an example, properly labeled, with caveats.

Secondly, most readers will understand that what happened in iMessage was, at the time, unique, and illustrative - the existing messaging app used for SMS was enhanced to have an IP interface, indistinguishable from SMS from the user’s point of view.  Other services may have copied that, but readers will know the significance of that service in the context of the discussion.

>  
> Another issue to consider (and it’s not just relevant for the  use of instant messaging) is the use of SIM roaming or “plastic roaming” where users who are travelling use either a SIM from pool of company provided local SIM cards or purchase a local prepaid SIM card in order to eliminate roaming charges. This means that the E.164 number of the user has changed but potentially the identity used by the instant messaging service remains the same as many mobile IM services identities are independent of the E.164 number being instead tied to email addresses or device identities. In many cases the smartphone doesn’t even know its E.164 number – it does with IMS though.
I’m having trouble understanding how this is relevant to stir.  If the network operator does the signing, then the fact that the phone changes isn’t relevant.  The operator has the correct credentials for the exchange.  If the device does the signing, then it will need to know the e.164, and it will need the key.  That’s potentially an issue (multiple devices having the private key), but that’s what you get when you share SIMs.

> I am not convinced that roaming (at least in the traditional sense of cellular roaming - and this will continue to be the case with IMS roaming) means that calls will emerge from administrative dom…
I see the point.  Maybe we want to soften “no relationship”. 

> Is this really a MUST strength requirement? Whatever solution we come up with that requires enhancement to SIP requires some enhancement. TCP is always available to use if message sizes become too large and since the deployed systems will need to be enhanced they can be (even should be) enhanced to support TCP. I think in many cases SIP and SDP has already grown to such an extent (ICE candidates, preconditions, SDP cap neg attributes, increasing number of codecs and media lines etc…) that we are already at the point where we are perilously close to or already over the 1300 byte recommendation in many scenarios.  Any size increase at all may break the camel’s back on the UDP fragmentation issue. I think at best this is guidance that message size is a factor to consider in evaluating a solution not an overriding requirement
>  
I’m okay with dropping this to should.