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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 4 Nov 2013 16:59:24 +0000

Hi Andrew,

Catching up on this mail; thanks for these comments, you have some good catches here. I think we're mostly cool but a couple points we might discuss further:

<AA>Section 6.1
<snip>

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

This text isn't trying to shill for any particular vendor, really it is just trying to provide an existence proof. I certainly wouldn't object to mentioning other similar services here that corroborate that existence proof.

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

The administrative domain has no relationship with the number assignee in the sense that the number assignee is not a customer of that administrative domain and doesn't pay money to it directly. Totally agreed that there are trust relationships between carriers that make roaming possible, but the relevant bit here for STIR is about who assigns the number and who serves the call. When I come here to Vancouver, my cell phone roams from AT&T to Rodgers. Rogers is not the carrier to whom my cell phone number is assigned for STIR purposes, but they serve my calls and texts while I'Mhere . Still, if this is confusing from the text we need to make it clearer.

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

Well, the "musts" here aren't normative, but I hear you. I don't have that strong an intuition about this.

Jon Peterson
Neustar, Inc.

---

From: Andrew Allen <[email-masked]>
Date: Mon, 4 Nov 2013 21:53:31 +0000

Jon

My responses inline

Andrew

From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, November 04, 2013 11:59 AM
To: Andrew Allen; [email-masked]
Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00

Hi Andrew,

<AA>Section 6.1
<snip>

This text isn't trying to shill for any particular vendor, really it is just trying to provide an existence proof. I certainly wouldn't object to mentioning other similar services here that corroborate that existence proof.
[AA] Is there anything special about iMessage of potential relevance in STIR problem space that isn't reflected by many of the other mobile messaging services out there that make it worthy of being a good example over others or over mobile IM applications in general? I don't think just the fact that some people happen to be familiar with iMessage is sufficient justification to make it a good example to use in the draft - particularly since it has short comings such as being currently restricted to a single platform. I believe Whatsapp has the most user's and also has multi vendor support. I suppose a list of e.g's is OK but I don't see why we need to describe in any detail a specific service - since most of them have similar characteristics.
<AA>Section 6.5

[AA] My problem is with the statement "domains that have no relationship with the number assignee" Certainly they have a relationship - in fact a close and trusted one and the home domain provides the number to assert to the roamed to domain.  So I think it needs to be made clearer.

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

[AA] OK.  It's an advantage to be smaller but it's not overiding

Jon Peterson
Neustar, Inc.
---------------------------------------------------------------------
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: "Peterson, Jon" <[email-masked]>
Date: Mon, 4 Nov 2013 23:26:23 +0000

<AA>I don’t think just the fact that some people happen to be familiar with iMessage is sufficient justification to make it a good example to use in the draft – particularly since it has short comings such as being currently restricted to a single platform. I believe Whatsapp has the most user’s and also has multi vendor support. I suppose a list of e.g’s is OK but I don’t see why we need to describe in any detail a specific service – since most of them have similar characteristics.</AA>

I think the fact that people are familiar with iMessage is a very good reason to list it as one example. I'm happy to include other examples, including Whatsapp. I would also be happy to make the descriptive text there less specific to any particular vendor, but I do have a hard time seeing how listing iMessage here would make people misunderstand the problem statement.

[AA] My problem is with the statement “domains that have no relationship with the number assignee” Certainly they have a relationship – in fact a close and trusted one and the home domain provides the number to assert to the roamed to domain.  So I think it needs to be made clearer.

Okay, per the text I sent in my last mail, we can make this clearer. Again, what this means for STIR is that the the roaming carrier won't have the authority over the number.

Jon Peterson
Neustar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Nov 2013 20:27:02 -0500

Jon .. what about NO don't you understand.  

We object to the references. Remove them now. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peterson, Jon
Sent: Monday, November 04, 2013 6:26 PM
To: Andrew Allen; [email-masked]
Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00

<AA>I don't think just the fact that some people happen to be familiar with
iMessage is sufficient justification to make it a good example to use in the
draft - particularly since it has short comings such as being currently
restricted to a single platform. I believe Whatsapp has the most user's and
also has multi vendor support. I suppose a list of e.g's is OK but I don't
see why we need to describe in any detail a specific service - since most of
them have similar characteristics.</AA>

I think the fact that people are familiar with iMessage is a very good
reason to list it as one example. I'm happy to include other examples,
including Whatsapp. I would also be happy to make the descriptive text there
less specific to any particular vendor, but I do have a hard time seeing how
listing iMessage here would make people misunderstand the problem statement.

[AA] My problem is with the statement "domains that have no relationship
with the number assignee" Certainly they have a relationship - in fact a
close and trusted one and the home domain provides the number to assert to
the roamed to domain.  So I think it needs to be made clearer.

Okay, per the text I sent in my last mail, we can make this clearer. Again,
what this means for STIR is that the the roaming carrier won't have the
authority over the number. 

Jon Peterson

Neustar, Inc.

---

From: Michael Hammer <[email-masked]>
Date: Tue, 5 Nov 2013 15:50:42 +0000

Jon,

It would be possible to describe the salient features of any given service
without naming it.

I think the principle proposed is to not denigrate nor promote any
particular vendor's implementation.

One could argue that you will cross the line of misappropriating some
vendor's IPR.

Not sure if anyone has asked the vendor in question if they want to be named
in an ID.

Using IETF solutions and naming them is probably OK, since that is public.

Concerning roaming service providers (carriers may have regulatory
implications), 

visited system are given the crypto-credentials with which to authenticate a
user 

that can then make outbound calls from that visited system.  

It is certainly possible that additional credentials could be extended from
the home network 

to the visited one to use to authenticate the calling party to the called
party.  That however 

would likely require some liaison with 3GPP to determine what attributes and
functions 

should be supported in mobile network.  

Has the IETF considered what might be adopted into IMS, VoLTE and such?

Mike

Jon Peterson

Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Nov 2013 16:46:31 +0000

I can see in principle how it might seem to make little difference if we were to replace mentions of any vendor(s) with a description of services which have this property, which have been deployed to hundreds of millions of endpoints, and which establish that an out-of-band identity system is possible. Maybe that is where we ultimately need to go here. I'll have a slide to discuss this today.

The problem is that the single paragraph of the problem-statement document that references "that vendor" is part of a larger section called "Environmental Changes," and the first sentence of that paragraph makes it clear we are talking about "shifts in the communications marketplace," not just technical ideas that may or may not have been implemented or deployed. I maintain that specific existence proofs are necessary to explain why we are revisiting identity today. Or to put it differently, there have been arguments on this list that an out-of-band identity system is simply not viable, a non-starter, and removing obvious existence proof examples from the problem-statement draft would seem to bolster those arguments at the cost of disconnecting our work from the reality of the marketplace. That's why I think references to actual deployed systems should remain.

Regarding roaming, agreed that there are conceivable ways to work roaming into the credential systems we're considering. I think we're a pretty long way from considering transport-specific implications of this work. The only points we need to capture here in the problem statement are the points about authority, I think.

Jon Peterson
Neustar, Inc.

From: Michael Hammer <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 5, 2013 7:50 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] comments on draft-ietf-stir-problem-statement-00

Jon,

It would be possible to describe the salient features of any given service without naming it.
I think the principle proposed is to not denigrate nor promote any particular vendor’s implementation.
One could argue that you will cross the line of misappropriating some vendor’s IPR.
Not sure if anyone has asked the vendor in question if they want to be named in an ID.
Using IETF solutions and naming them is probably OK, since that is public.

Concerning roaming service providers (carriers may have regulatory implications),
visited system are given the crypto-credentials with which to authenticate a user
that can then make outbound calls from that visited system.

It is certainly possible that additional credentials could be extended from the home network
to the visited one to use to authenticate the calling party to the called party.  That however
would likely require some liaison with 3GPP to determine what attributes and functions
should be supported in mobile network.
Has the IETF considered what might be adopted into IMS, VoLTE and such?

Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Monday, November 04, 2013 6:26 PM
To: Andrew Allen; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] comments on draft-ietf-stir-problem-statement-00

Jon Peterson
Neustar, Inc.