Subject: [cnit] Restarting the CNAM CNIT proposition at IETF 91

From: "Richard Shockey" <[email-masked]>
Date: Mon, 18 Aug 2014 12:59:13 -0400

I have reason to believe it may be useful to revisit the CNAM CNIT
proposition during DISPATCH at 91 and see if there is consensus on moving
forward on some level of standardization here.

The idea is pretty simple.  We all generally know what CNAM in the PSTN is.
(see below) Calling Name Delivery information is the verbose ASCII text
delivered to the User Agent in conjunction with the Caller ID number of the
calling party.  It is typically delivered as a terminating service in SS7
via TCAP from LIDB databases.

CNAM as it is currently defined in SS7 is a terrible service.  15 Character
ASCII.  No support for International characters etc.  It has not, to my
knowledge, been widely deployed in mobile access networks.  CNAM in SIP this
has generally been an afterthought. 

It is not a hard stretch to postulate that called parties might like a
richer set of data displayed on their UA's and that can be delivered by the
SIP headers in some relatively simple form at session origination.
Modification or a repurposing of the Call-Info header for instance might be
a simple way to start.  Incorporation of logos, pictures whatever including
presentation formats for STIR validation data etc. 

Creation and transmission is fully governed by existing SIP privacy
mechanisms. 

Display at termination is governed by UA or service provider policy. 

There is every reason to  National Regulators would be delighted with
consumers having a richer set of information displayed on their handsets in
order to make more informed decisions on whether to accept the session.
"Is this really my bank calling me?"   

Considering the progress being made in STIR is seems logical to revisit the
issue more formally.   The Caller ID spoofing problem has not gone away and
STIR, by itself, is no 'silver bullet'. I think we have all understood that.

There are some interesting aspects of this. There are clearly privacy
considerations however I would argue that the privacy of the called party is
what we are trying to protect here. In addition we do not want to see the
technique itself become a form of SPAM flooding UA's.

What I would propose is a Charter of very very narrow scope.  MARTINI as the
model. 

1.      What SIP header would carry the CNAM Plus object?

2.      What would a CNAM Plus object look like? JSON <duh> 

3.      How is STIR validation data delivered to the UA, presuming that STIR
continues to progress.

I would rule out of scope any discussion of how the data in the CNAM Plus
object is created, stored, or how its origin is determined or managed.  We
do not want to run down the rat hole of who determines that this Bank or
this Doctor is actually the one that creates the data object.  That IMHO is
someone else's problem. 

My suspicion is that the IETF is going to need some very close coordination
with 3GPP here.  I have on good authority 3GPP is looking into some of these
issues on an informal basis now in the review of STIR progress etc.
Obviously given the ongoing global launch of VoLTE services this work should
be of strong interest. 

I'm willing to take a first cut at a Problem Statement and Requirements so
I'm looking for collaborators here. 

Second we have a list established for this already CNIT..it seems logical to
confine the technical discussion there except for the obvious DISPATCH
issues etc expressions of interest support etc. 

cnit mailing list

[email-masked] <mailto:[email-masked]> 

https://www.ietf.org/mailman/listinfo/cnit

Thoughts? 

 

******************

American National Standards Institute (ANSI), Telecommunications
Network-to-Customer Installation Interfaces - Analog Voice grade  Switched
Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual
Message-Waiting Indicator Features, ANSI  T1.6401.03-1998 

American National Standards Institute (ANSI), Telecommunications- Integrated
Services Digital Network (ISDN) - Calling Line Identification Presentation
and Restriction Supplementary Services, ANSI T1.625-1993

American National Standards Institute ANSI), Telecommunications - Calling
Name Identification Presentation, ANSI T1.641-1995 

Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic
Requirements", GR-1188-CORE, Issue 2, December 2000

Telcordia Technologies, "CLASS Feature: Calling Number Delivery",
GR-31-CORE, Issue 1, June 2000

Richard Shockey
Shockey Consulting LLC 

http://www.shockey.us
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
< <mailto:richard(at)shockey.us> mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http://www.sipforum.org

"Money is the answer, what is the question?" tm

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 18 Aug 2014 19:29:12 +0000

Thanks for re-starting the discussion. Before getting into the header details, having a clearer understanding of the requirements would be useful. To start, I'll posit four:

(1)    Traceable origin: It must be clear to the recipient who vouches for the information. (Assertion of the calling party? Some licensing authority such as a financial regulator or a professional association? Originating carrier? Third-party database?)

(2)    By value and/or by reference: In the location context, we have had long discussions about the trade-offs and I suspect we can learn from that debate. By reference gives you easier scaling to large (possibly signed) objects and differentiated access control. By value requires fewer moving parts. Allowing for both may allow for trade-offs rather than endless arguments.

(3)    Extensibility and rendering: Given the diversity of end systems, ranging from very small screens that are only suited for ASCII and text-to-speech systems, to desktop displays, we want this to work reasonably well across the range of devices, and probably also accommodate different consumer needs (including supporting people with hearing or visual disabilities), along with robots that use the information to make call routing and call handling decisions.

(4)    Privacy: The existing CNAM system has the disadvantage that anybody can find out the name behind any number, rather than just the callee. While nobody can prevent the callee from posting information on http://800notes.com/, there may be ways to protect the interests of both caller and callee that make systematic and large-scale collection of reverse mappings more labor-intensive, particularly to protect the reasonable expectations of private individuals.

From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; [email-masked]
Cc: [email-masked]
Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91

I have reason to believe it may be useful to revisit the CNAM CNIT proposition during DISPATCH at 91 and see if there is consensus on moving forward on some level of standardization here.

The idea is pretty simple.  We all generally know what CNAM in the PSTN is. (see below) Calling Name Delivery information is the verbose ASCII text delivered to the User Agent in conjunction with the Caller ID number of the calling party.  It is typically delivered as a terminating service in SS7 via TCAP from LIDB databases.

CNAM as it is currently defined in SS7 is a terrible service.  15 Character ASCII.  No support for International characters etc.  It has not, to my knowledge, been widely deployed in mobile access networks.  CNAM in SIP this has generally been an afterthought.

It is not a hard stretch to postulate that called parties might like a richer set of data displayed on their UA's and that can be delivered by the SIP headers in some relatively simple form at session origination. Modification or a repurposing of the Call-Info header for instance might be a simple way to start.  Incorporation of logos, pictures whatever including presentation formats for STIR validation data etc.

Creation and transmission is fully governed by existing SIP privacy mechanisms.

There is every reason to  National Regulators would be delighted with consumers having a richer set of information displayed on their handsets in order to make more informed decisions on whether to accept the session.   "Is this really my bank calling me?"

Considering the progress being made in STIR is seems logical to revisit the issue more formally.   The Caller ID spoofing problem has not gone away and STIR, by itself, is no 'silver bullet'. I think we have all understood that.

There are some interesting aspects of this. There are clearly privacy considerations however I would argue that the privacy of the called party is what we are trying to protect here. In addition we do not want to see the technique itself become a form of SPAM flooding UA's.

What I would propose is a Charter of very very narrow scope.  MARTINI as the model.

3.      How is STIR validation data delivered to the UA, presuming that STIR continues to progress.

I would rule out of scope any discussion of how the data in the CNAM Plus object is created, stored, or how its origin is determined or managed.  We do not want to run down the rat hole of who determines that this Bank or this Doctor is actually the one that creates the data object.  That IMHO is someone else's problem.

My suspicion is that the IETF is going to need some very close coordination with 3GPP here.  I have on good authority 3GPP is looking into some of these issues on an informal basis now in the review of STIR progress etc. Obviously given the ongoing global launch of VoLTE services this work should be of strong interest.

I'm willing to take a first cut at a Problem Statement and Requirements so I'm looking for collaborators here.

Second we have a list established for this already CNIT..it seems logical to confine the technical discussion there except for the obvious DISPATCH issues etc expressions of interest support etc.

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

Thoughts?

******************

American National Standards Institute (ANSI), Telecommunications Network-to-Customer Installation Interfaces - Analog Voice grade  Switched Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator Features, ANSI  T1.6401.03-1998

American National Standards Institute (ANSI), Telecommunications- Integrated Services Digital Network (ISDN) - Calling Line Identification Presentation and Restriction Supplementary Services, ANSI T1.625-1993

American National Standards Institute ANSI), Telecommunications - Calling Name Identification Presentation, ANSI T1.641-1995

Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2, December 2000

Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, June 2000

Richard Shockey
Shockey Consulting LLC
http://www.shockey.us
<mailto:richard(at)shockey.us>

---

From: Hala Mowafy <[email-masked]>
Date: Tue, 19 Aug 2014 04:50:32 +0000

Before we go any further on discussing CNAM, we need to clarify the terminology so we can have a productive discussion and more importantly to prevent any confusion.

-        CNAM is a term that the industry uses to refer to a terminating service where the called party receives the name on an incoming call.  It is already used in Standards to refer to that terminating service.

-        The called party does NOT proactively seek or discover the name, as in a Google look up.  Name is delivered to them.

-        Called party has no choice over the source, e.g., which database to query for the name.  For most CNAM offerings, the service provider chooses that database.

-        In the CNAM service model, since the service provider has business agreements with the database owner, the name would be considered "traceable" - again, only by the service provider, and not by the calling or called parties.  If you, the database owner, have an agreement with the entity accessing your database, you have control and you can take legal action if someone tries to "drain" your database or cache data from it.

-        The other sources of "name" that are available online or otherwise, should not be referred to as CNAM.  You may call them "name lookups" or something else other than CNAM.

From: stir [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Monday, August 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; [email-masked]
Cc: [email-masked]
Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91

From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91

cnit mailing list

Thoughts?

******************

Richard Shockey
Shockey Consulting LLC
http://www.shockey.us

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Aug 2014 18:45:58 +0000

Hala,

I don't think we're disagreeing, but if anything I said is at odds with your description, please say so. I was referring to the many services that provide an API-based service that appears to rely on the same databases for caller name delivery.

At least for many telecom service providers, they seem to draw on multiple LIDB providers, including sometimes configure-your-own-message services like CallerID4U, and, at least to the recipient, it is hard to know how, if at all, this information has been validated.

Given the potential confusion and since it doesn't seem particularly productive to get into how a legacy service is defined, maybe "textual callerID" is the better term.

Henning

From: Hala Mowafy [mailto:[email-masked]]
Sent: Tuesday, August 19, 2014 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91

From: stir [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Henning Schulzrinne
Sent: Monday, August 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91

cnit mailing list

Thoughts?

******************

Richard Shockey
Shockey Consulting LLC
http://www.shockey.us

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Aug 2014 15:09:55 -0400

Ok.  At the very least we can assume there is interest in the work.  

As for what we call this I really don't care but we generally know what CNAM
is right now and the existing service is somewhat useless can be spoofed and
is a contributing factor to the overall problem of fraud and abuse that
deeply concerns our National Regulators. 

We can call it what every you want.  Alas we don't have Hadrial Kaplan any
more to dream up catchy names.

What I'd like to avoid, though that may not be possible, is a long running
discussion of the policy questions associated with the service and the
design implications.  I was trying to focus attention on to basic elements.
One is the object itself that carries the more extensive calling party
information and second how SIP actually carries it.  As Henning points out
this may be more complicated with multimedia elements necessary to
accommodate those with disabilities.  

This may require a more extensive Problem Statement and Requirements
incorporating Policy Considerations but we all know what that means
especially if it involves numbering databases or databases indexed by
numbering.  I just don't want to dive too far into the weeds just yet.  That
may be impossible but I'm sure this discussion will flush that out. 

Privacy is a complicated problem but I start from the inference that it is
the called party we are trying to protect here.  You have no right to
arbitrarily contact me unless I have some mechanism to validate who you are.
"Are you really my bank?"  As a personal side bar I'm never going to accept
a point to point SIP/IMS/RCS video call from anyone unless I have some
better data on who is calling me. 

SIP and realtime communications are not email. We are not invalidating
existing SIP privacy mechanisms only making sure that the called party has
sufficient information to make a reasoned judgment whether to accept the
session or not.  The calling party can still refuse to send Enhanced Calling
Party Name Information or suppress the CLI for instance.  

I will certainly admit to a bias that designing a system around the service
providers that issued the phone numbers to the parties is not a bad place to
start.  Last but not least .. we have no business discussing business
models.  I would argue that the security of PII related databases is out of
scope. 

From: cnit [mailto:[email-masked]] On Behalf Of Hala Mowafy
Sent: Tuesday, August 19, 2014 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; [email-masked]
Cc: [email-masked]
Subject: Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91

Before we go any further on discussing CNAM, we need to clarify the
terminology so we can have a productive discussion and more importantly to
prevent any confusion.

-        CNAM is a term that the industry uses to refer to a terminating
service where the called party receives the name on an incoming call.  It is
already used in Standards to refer to that terminating service.

-        The called party does NOT proactively seek or discover the name, as
in a Google look up.  Name is delivered to them.

-        Called party has no choice over the source, e.g., which database to
query for the name.  For most CNAM offerings, the service provider chooses
that database.

-        In the CNAM service model, since the service provider has business
agreements with the database owner, the name would be considered "traceable"
- again, only by the service provider, and not by the calling or called
parties.  If you, the database owner, have an agreement with the entity
accessing your database, you have control and you can take legal action if
someone tries to "drain" your database or cache data from it.  

-        The other sources of "name" that are available online or otherwise,
should not be referred to as CNAM.  You may call them "name lookups" or
something else other than CNAM.

From: stir [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Monday, August 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91

Thanks for re-starting the discussion. Before getting into the header
details, having a clearer understanding of the requirements would be useful.
To start, I'll posit four:

(1)    Traceable origin: It must be clear to the recipient who vouches for
the information. (Assertion of the calling party? Some licensing authority
such as a financial regulator or a professional association? Originating
carrier? Third-party database?)

(2)    By value and/or by reference: In the location context, we have had
long discussions about the trade-offs and I suspect we can learn from that
debate. By reference gives you easier scaling to large (possibly signed)
objects and differentiated access control. By value requires fewer moving
parts. Allowing for both may allow for trade-offs rather than endless
arguments.

(3)    Extensibility and rendering: Given the diversity of end systems,
ranging from very small screens that are only suited for ASCII and
text-to-speech systems, to desktop displays, we want this to work reasonably
well across the range of devices, and probably also accommodate different
consumer needs (including supporting people with hearing or visual
disabilities), along with robots that use the information to make call
routing and call handling decisions.

(4)    Privacy: The existing CNAM system has the disadvantage that anybody
can find out the name behind any number, rather than just the callee. While
nobody can prevent the callee from posting information on
http://800notes.com/, there may be ways to protect the interests of both
caller and callee that make systematic and large-scale collection of reverse
mappings more labor-intensive, particularly to protect the reasonable
expectations of private individuals. 

From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91

 

cnit mailing list

Thoughts? 

 

******************

 

Richard Shockey
Shockey Consulting LLC 

http://www.shockey.us

---

From: Michael Hammer <[email-masked]>
Date: Wed, 20 Aug 2014 21:44:51 +0000

Richard,

I doubt you can avoid policy and business models.

The minute you pose the architectural question of whether this is true
peer-to-peer (aka a protocol independent of SIP), 

or must be provided by the service provider (aka part of the
carrier-controled SIP path), you have already slid down that slope.

If there were no business need, then no one would need this work.

________________________________

Michael Hammer

Principal Engineer

 <mailto:[email-masked]> [email-masked]

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

 <http://www.yaanatech.com/> www.yaanatech.com

From: dispatch [mailto:[email-masked]] On Behalf Of Richard
Shockey
Sent: Wednesday, August 20, 2014 3:10 PM
To: 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition
at IETF 91

 

 

 

cnit mailing list

[email-masked]

Thoughts? 

 

******************

 

Richard Shockey
Shockey Consulting LLC 

http://www.shockey.us

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 20 Aug 2014 21:10:10 -0400

Richard,

[RS> ] Agreed but not in the IETF or 3GPP. My overriding concern in trying
to restart this discussion is to limit the scope of what we do.  We meaning
the stewards of SIP etc.  It is my strong preference, and I will try and
insist on, keeping the focus of the work only on what goes "on the wire" .
We are not competent to make policy or business model judgments especially
on areas related to telephony vs "the Internet". 

IMHO any reasonable deployment scenario for whatever we call this would end
up being part of some other SDO's work.  In North America that would
probably be my friends at ATIS which works closely with the FCC and the CRTC
in Canada or in the UK the NICC which performs a similar technical advisory
function for OFCOM.  Would ETSI get involved for Europe as a whole..
Probably.  We are not there and nor should we go there.  Its perfectly
reasonable for the IETF as technical experts to describe 'Policy
Considerations' but beyond that we are out of our league.

If I could use the magic wand I look at repurposing the Call-Info header and
maybe RFC 7095 expressed as a URI signed by STIR.

http://tools.ietf.org/html/rfc7095

Permit the rewriting of Call-Info header for carrier STIR validation text or
something.  "Trusted by Vodafone" "Not Validated" Something in the INVITE to
the UA that can be displayed. Which is why this is so important to VoLTE and
the mobile handsets. In VoLTE the INVITE reaches the handset so yes it
really is a issue for Apple and Android as well.  Not to mention how WEBRTC
deals with Calling Party Info.  It's the Public SIP Telephone Network now
after all for interconnection. 

[RS> ]  You want to do peer to peer go ahead. IMHO you are out of scope for
this work. Stick to what is on the wire. 

[RS> ] IMHO this is not a business need, though there is certainly a
business model to support the deployment of this.  What are we trying to do
here?  You don't need me to explain that the contagion of Caller ID spoofing
is driving consumers crazy and driving National Regulatory Authorities crazy
as well.  I would argue that STIR and this effort is a perfectly reasonable
Consumer Protection effort.  That is honorable work we all could be proud
of. 

Can't we make SIP safer for people to use?  I am not a regulator nor do I
play one on TV but this IMHO is exactly the kind of thing we as technical
professionals and the IETF .. (don't get me started on ISOC) should do.  It
could be pretty simple stuff and it WILL have a demonstrable and positive
impact on the lives of thousands indeed millions that are dealing with this
every single day. 

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

<mailto:[email-masked]> 

 

<mailto:[email-masked]> 

 

 

cnit mailing list

Thoughts? 

 

******************

 

Richard Shockey
Shockey Consulting LLC 

http://www.shockey.us

---

From: Michael Hammer <[email-masked]>
Date: Thu, 21 Aug 2014 13:12:52 +0000

No disagreement with anything you have said.

But, the IETF often creates separate protocols rather than bundling
everything into a single protocol.

I was only pointing out that other possibility and that decision is the
first one to be made.

If it is decided that it should still be part of SIP, then I gather you just
want to define some syntax, 

and then let whomever to decide what to do with it according to their
business model.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: Richard Shockey [mailto:[email-masked]] 
Sent: Wednesday, August 20, 2014 9:10 PM
To: Michael Hammer; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition
at IETF 91

Richard,

 

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

 

 

 

cnit mailing list

[email-masked]

Thoughts? 

 

******************

 

Richard Shockey
Shockey Consulting LLC 

http://www.shockey.us

---

From: Hala Mowafy <[email-masked]>
Date: Thu, 21 Aug 2014 13:33:17 +0000

Henning,
We agree on the end result: reliable ID delivery.  My point is that the discussion keeps crossing the problems of one set of "name related" services with others.
For LIDBs and CNAM, the service providers perform a certain level of validation when you start service with them (checking a personal ID, a business tax ID, address, etc.), which aligns in principle with the goals of strengthening the trust in the "originating" side (such as the goals of STIR).  It is not a digital certificate, but it provides some verification.

The major carriers I deal with will not allow anyone to list a phony name in LIDB.   I don't know of any LIDB provider that allows the customer a "configure-your-own-message," either.  But I would welcome any examples if you've run into some rogue LIDBs.
In contrast, some companies, as you mentioned, may simply get paid to deliver whatever Caller ID/Name you want displayed to the parties you call.  To my knowledge, again, that is NOT using a LIDB.
So when I read the email threads, I ask: Shouldn't we "objectively" look at what works and what doesn't and design a system with the best of everything that has a proven track record?  I trust we will.

Last but not least: work is underway at ATIS PTSC to extend CNAM to 60 characters along with possible enhancements.

From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, August 20, 2014 2:46 PM
To: Hala Mowafy; 'Richard Shockey'; 'DISPATCH'; [email-masked]
Cc: [email-masked]
Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91

Hala,

Henning

To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; [email-masked]<mailto:[email-masked]>

cnit mailing list

Thoughts?

******************

Richard Shockey
Shockey Consulting LLC
http://www.shockey.us

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Aug 2014 10:55:51 -0400

On 8/20/14 9:10 PM, Richard Shockey wrote:
> */[RS> ] Agreed but not in the IETF or 3GPP. My overriding concern in
> trying to restart this discussion is to limit the scope of what we do.
> We meaning the stewards of SIP etc.  It is my strong preference, and I
> will try and insist on, keeping the focus of the work only on what goes
> “on the wire” . We are not competent to make policy or business model
> judgments especially on areas related to telephony vs “the Internet”. /*
>
> *//*
>
> */IMHO any reasonable deployment scenario for whatever we call this
> would end up being part of some other SDO’s work.  In North America that
> would probably be my friends at ATIS which works closely with the FCC
> and the CRTC in Canada or in the UK the NICC which performs a similar
> technical advisory function for OFCOM.  Would ETSI get involved for
> Europe as a whole.. Probably.  We are not there and nor should we go
> there.  Its perfectly reasonable for the IETF as technical experts to
> describe ‘Policy Considerations’ but beyond that we are out of our league./*
>
> *//*

I'm suspect that some of the policy decisions can be deferred as you 
suggest, but I also suspect that there are architectural issues that 
affect those policy issues.

At the end of the day the callee will receive an assertion: X says the 
name of the caller is Y. Then the callee, or the callee's device, must 
decide if he/it is willing to trust such an assertion for X.

If the actual callee is presented with both X and Y, then perhaps he can 
make the trust decision on a case-by-case basis. But this is probably 
impractical. Instead, it is likely that the callee's device will be 
making the trust decision, and using it to make some policy decisions on 
behalf of the callee: to accept/reject the call, to display Y or not, 
etc. How can it make those decisions without some standards for whether 
to trust X or not?

The "obvious" answer in the context of STIR is that I should trust X's 
assertion of Y if I trust X's STIR assertion of the calling number. But 
that doesn't seem like a good conclusion without some standards.

	Thanks,
	Paul

> */If I could use the magic wand I look at repurposing the Call-Info
> header and maybe RFC 7095 expressed as a URI signed by STIR./*
>
> *//*
>
> */http://tools.ietf.org/html/rfc7095/*
>
> *//*
>
> */Permit the rewriting of Call-Info header for carrier STIR validation
> text or something.  “Trusted by Vodafone” “Not Validated” Something in
> the INVITE to the UA that can be displayed. Which is why this is so
> important to VoLTE and the mobile handsets. In VoLTE the INVITE reaches
> the handset so yes it really is a issue for Apple and Android as well.
> Not to mention how WEBRTC deals with Calling Party Info.  It’s the
> Public SIP Telephone Network now after all for interconnection. /*
>
> */[RS> ]  You want to do peer to peer go ahead. IMHO you are out of
> scope for this work. Stick to what is on the wire. /*
>
> */[RS> ] IMHO this is not a business need, though there is certainly a
> business model to support the deployment of this.  What are we trying to
> do here?  You don’t need me to explain that the contagion of Caller ID
> spoofing is driving consumers crazy and driving National Regulatory
> Authorities crazy as well.  I would argue that STIR and this effort is a
> perfectly reasonable Consumer Protection effort.  That is honorable work
> we all could be proud of. /*
>
> *//*
>
> */Can’t we make SIP safer for people to use?  I am not a regulator nor
> do I play one on TV but this IMHO is exactly the kind of thing we as
> technical professionals and the IETF .. (don’t get me started on ISOC)
> should do.  It could be pretty simple stuff and it WILL have a
> demonstrable and positive impact on the lives of thousands indeed
> millions that are dealing with this every single day. /*
>
> *________________________________*
>
> *Michael Hammer*
>
> *Principal Engineer*
>
> [email-masked] <mailto:[email-masked]>_
>
> *Mobile: *+1**408 202 9291
>
> 542 Gibraltar Drive
>
> Milpitas, CA 95035 USA
>
> www.yaanatech.com <http://www.yaanatech.com/>
>
> *From:*dispatch [mailto:[email-masked]] *On Behalf Of
> *Richard Shockey
> *Sent:* Wednesday, August 20, 2014 3:10 PM
> *To:* 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; [email-masked]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT
> proposition at IETF 91
>
> As for what we call this I really don’t care but we generally know what
> CNAM is right now and the existing service is somewhat useless can be
> spoofed and is a contributing factor to the overall problem of fraud and
> abuse that deeply concerns our National Regulators.
>
> We can call it what every you want.  Alas we don’t have Hadrial Kaplan
> any more to dream up catchy names.
>
> What I’d like to avoid, though that may not be possible, is a long
> running discussion of the policy questions associated with the service
> and the design implications.  I was trying to focus attention on to
> basic elements. One is the object itself that carries the more extensive
> calling party information and second how SIP actually carries it.  As
> Henning points out this may be more complicated with multimedia elements
> necessary to accommodate those with disabilities.
>
> numbering.  I just don’t want to dive too far into the weeds just yet.
>   That may be impossible but I’m sure this discussion will flush that out.
>
> Privacy is a complicated problem but I start from the inference that it
> is the called party we are trying to protect here.  You have no right to
> arbitrarily contact me unless I have some mechanism to validate who you
> are. “Are you really my bank?”  As a personal side bar I’m never going
> to accept a point to point SIP/IMS/RCS video call from anyone unless I
> have some better data on who is calling me.
>
> existing SIP privacy mechanisms only making sure that the called party
> has sufficient information to make a reasoned judgment whether to accept
> the session or not.  The calling party can still refuse to send Enhanced
> Calling Party Name Information or suppress the CLI for instance.
>
> I will certainly admit to a bias that designing a system around the
> service providers that issued the phone numbers to the parties is not a
> bad place to start.  Last but not least .. we have no business
> discussing business models.  I would argue that the security of PII
> related databases is out of scope.
>
> *From:* cnit [mailto:[email-masked]] *On Behalf Of *Hala Mowafy
> *Sent:* Tuesday, August 19, 2014 12:51 AM
> *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; [email-masked]
> <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91
>
> terminology so we can have a productive discussion and more importantly
> to prevent any confusion.
>
> -CNAM is a term that the industry uses to refer to a terminating service
> where the called party receives the name on an incoming call.  It is
> -The called party does NOT proactively seek or discover the name, as in
> a Google look up.  Name is delivered to them.
>
> -Called party has no choice over the source, e.g., which database to
> query for the name.  For most CNAM offerings, the service provider
> chooses that database.
>
> -In the CNAM service model, since the service provider has business
> agreements with the database owner, the name would be considered
> “traceable” – again, only by the service provider, and not by the
> calling or called parties.  If you, the database owner, have an
> agreement with the entity accessing your database, you have control and
> you can take legal action if someone tries to “drain” your database or
> cache data from it.
>
> -The other sources of “name” that are available online or otherwise,
> should not be referred to as CNAM.  You may call them “name lookups” or
> *From:*stir [mailto:[email-masked]] *On Behalf Of *Henning
> Schulzrinne
> *Sent:* Monday, August 18, 2014 3:29 PM
> *To:* 'Richard Shockey'; 'DISPATCH'; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [stir] Restarting the CNAM CNIT proposition at IETF 91
>
> details, having a clearer understanding of the requirements would be
> useful. To start, I’ll posit four:
>
> (1)/Traceable origin/: It must be clear to the recipient who vouches for
> the information. (Assertion of the calling party? Some licensing
> authority such as a financial regulator or a professional association?
> Originating carrier? Third-party database?)
>
> (2)/By value and/or by reference/: In the location context, we have had
> long discussions about the trade-offs and I suspect we can learn from
> that debate. By reference gives you easier scaling to large (possibly
> signed) objects and differentiated access control. By value requires
> fewer moving parts. Allowing for both may allow for trade-offs rather
> than endless arguments.
>
> (3)/Extensibility and rendering/: Given the diversity of end systems,
> text-to-speech systems, to desktop displays, we want this to work
> reasonably well across the range of devices, and probably also
> accommodate different consumer needs (including supporting people with
> hearing or visual disabilities), along with robots that use the
> information to make call routing and call handling decisions.
>
> (4)/Privacy/: The existing CNAM system has the disadvantage that anybody
> can find out the name behind any number, rather than just the callee.
> While nobody can prevent the callee from posting information on
> caller and callee that make systematic and large-scale collection of
> reverse mappings more labor-intensive, particularly to protect the
> reasonable expectations of private individuals.
>
> *From:*stir [mailto:[email-masked]] *On Behalf Of *Richard Shockey
> *Sent:* Monday, August 18, 2014 12:59 PM
> *To:* 'DISPATCH'; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* [stir] Restarting the CNAM CNIT proposition at IETF 91
>
> proposition during DISPATCH at 91 and see if there is consensus on
> moving forward on some level of standardization here.
>
> The idea is pretty simple.  We all generally know what CNAM in the PSTN
> is. (see below) Calling Name Delivery information is the verbose ASCII
> text delivered to the User Agent in conjunction with the Caller ID
> number of the calling party.  It is typically delivered as a terminating
> service in SS7 via TCAP from LIDB databases.
>
> CNAM as it is currently defined in SS7 is a terrible service.  15
> Character ASCII.  No support for International characters etc.  It has
> not, to my knowledge, been widely deployed in mobile access networks.
>   CNAM in SIP this has generally been an afterthought.
>
> richer set of data displayed on their UA's and that can be delivered by
> the SIP headers in some relatively simple form at session origination.
> Modification or a repurposing of the Call-Info header for instance might
> be a simple way to start.  Incorporation of logos, pictures whatever
> including presentation formats for STIR validation data etc.
>
> consumers having a richer set of information displayed on their handsets
> in order to make more informed decisions on whether to accept the
> session.   “Is this really my bank calling me?”
>
> Considering the progress being made in STIR is seems logical to revisit
> the issue more formally.   The Caller ID spoofing problem has not gone
> away and STIR, by itself, is no ‘silver bullet’. I think we have all
> understood that.
>
> considerations however I would argue that the privacy of the called
> party is what we are trying to protect here. In addition we do not want
> to see the technique itself become a form of SPAM flooding UA’s.
>
> 1.What SIP header would carry the CNAM Plus object?
>
> 2.What would a CNAM Plus object look like? JSON <duh>
>
> 3.How is STIR validation data delivered to the UA, presuming that STIR
> continues to progress.
>
> I would rule out of scope any discussion of how the data in the CNAM
> Plus object is created, stored, or how its origin is determined or
> managed.  We do not want to run down the rat hole of who determines that
> this Bank or this Doctor is actually the one that creates the data
> object.  That IMHO is someone else’s problem.
>
> My suspicion is that the IETF is going to need some very close
> coordination with 3GPP here.  I have on good authority 3GPP is looking
> into some of these issues on an informal basis now in the review of STIR
> progress etc. Obviously given the ongoing global launch of VoLTE
> services this work should be of strong interest.
>
> I’m willing to take a first cut at a Problem Statement and Requirements
> so I’m looking for collaborators here.
>
> Second we have a list established for this already CNIT..it seems
> logical to confine the technical discussion there except for the obvious
> DISPATCH issues etc expressions of interest support etc.
>
> cnit mailing list
>
> Network-to-Customer Installation Interfaces - Analog Voice grade
> Switched Access Lines with Calling Number Delivery, Calling Name
> Delivery, or Visual Message-Waiting Indicator Features, ANSI
> T1.6401.03-1998
>
> American National Standards Institute (ANSI), Telecommunications-
> Integrated Services Digital Network (ISDN) - Calling Line Identification
> Presentation and Restriction Supplementary Services, ANSI T1.625-1993
>
> American National Standards Institute ANSI), Telecommunications -
> Calling Name Identification Presentation, ANSI T1.641-1995
>
> _______________________________________________
> cnit mailing list
> [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Aug 2014 15:13:46 +0000

There are, at least, three different kinds of information that have different trust relationships:

(1) Physical address (for non-VoIP or facilities-based VoIP landlines): Generally, if you trust the originating carrier, they know that information. The address is often wrong or misleading for OTT VoIP or franchise-style settings, where the address would reflect some corporate HQ or billing address, not the caller's address.

(2) Name of business or individual: Carriers will know the billing name, but not if the account is pre-pay. Also, I suspect that they don't necessarily track changes in business names (particularly DBAs) as long as the bill gets paid. My guess is that even for post-pay, there are a fair number of errors - somebody else paying the bill, marriage/divorce, name changes, typos, ... For family wireless accounts, the account holder name is shown (for carriers like TMo that provide this at all - most don't). When I call somebody, it announces me as my wife's name.

(3) Property assertion: The most interesting information is often what kind of entity the caller is, e.g., whether the caller is actually a state-registered charity or a real medical provider or a licensed chimney sweep. The carrier won't have a clue today.

One of the problems with the current system is that the caller itself has no reliable way to find out what will be displayed to the callee, given that the database dip is done by the terminating carrier. As one random example of how things are changing, Google now offer a version of caller ID on Android (https://support.google.com/nexus/answer/3459196?hl=en).

For what it's worth, Kumiko Ono and I looked at this problem years ago, in the ARID proposal.

Henning

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, August 21, 2014 10:56 AM
To: [email-masked]
Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91

On 8/20/14 9:10 PM, Richard Shockey wrote:
> will try and insist on, keeping the focus of the work only on what 
> goes "on the wire" . We are not competent to make policy or business 
> model judgments especially on areas related to telephony vs "the 
> Internet". /*
>
> *//*
>
> would end up being part of some other SDO's work.  In North America 
> that would probably be my friends at ATIS which works closely with the 
> FCC and the CRTC in Canada or in the UK the NICC which performs a 
> similar technical advisory function for OFCOM.  Would ETSI get 
> involved for Europe as a whole.. Probably.  We are not there and nor 
> should we go there.  Its perfectly reasonable for the IETF as 
> technical experts to describe 'Policy Considerations' but beyond that 
> we are out of our league./*
>
> *//*

I'm suspect that some of the policy decisions can be deferred as you suggest, but I also suspect that there are architectural issues that affect those policy issues.

At the end of the day the callee will receive an assertion: X says the name of the caller is Y. Then the callee, or the callee's device, must decide if he/it is willing to trust such an assertion for X.

If the actual callee is presented with both X and Y, then perhaps he can make the trust decision on a case-by-case basis. But this is probably impractical. Instead, it is likely that the callee's device will be making the trust decision, and using it to make some policy decisions on behalf of the callee: to accept/reject the call, to display Y or not, etc. How can it make those decisions without some standards for whether to trust X or not?

The "obvious" answer in the context of STIR is that I should trust X's assertion of Y if I trust X's STIR assertion of the calling number. But that doesn't seem like a good conclusion without some standards.

	Thanks,
	Paul

> text or something.  "Trusted by Vodafone" "Not Validated" Something in 
> important to VoLTE and the mobile handsets. In VoLTE the INVITE 
> reaches the handset so yes it really is a issue for Apple and Android as well.
> Not to mention how WEBRTC deals with Calling Party Info.  It's the 
> business model to support the deployment of this.  What are we trying 
> to do here?  You don't need me to explain that the contagion of Caller 
> ID spoofing is driving consumers crazy and driving National Regulatory 
> Authorities crazy as well.  I would argue that STIR and this effort is 
> a perfectly reasonable Consumer Protection effort.  That is honorable 
> work we all could be proud of. /*
>
> *//*
>
> */Can't we make SIP safer for people to use?  I am not a regulator nor 
> technical professionals and the IETF .. (don't get me started on ISOC) 
> As for what we call this I really don't care but we generally know 
> what CNAM is right now and the existing service is somewhat useless 
> can be spoofed and is a contributing factor to the overall problem of 
> fraud and abuse that deeply concerns our National Regulators.
>
> We can call it what every you want.  Alas we don't have Hadrial Kaplan 
> What I'd like to avoid, though that may not be possible, is a long 
> basic elements. One is the object itself that carries the more 
> extensive calling party information and second how SIP actually 
> carries it.  As Henning points out this may be more complicated with 
> multimedia elements necessary to accommodate those with disabilities.
>
> numbering.  I just don't want to dive too far into the weeds just yet.
>   That may be impossible but I'm sure this discussion will flush that out.
>
> Privacy is a complicated problem but I start from the inference that 
> it is the called party we are trying to protect here.  You have no 
> right to arbitrarily contact me unless I have some mechanism to 
> validate who you are. "Are you really my bank?"  As a personal side 
> bar I'm never going to accept a point to point SIP/IMS/RCS video call 
> from anyone unless I have some better data on who is calling me.
>
> has sufficient information to make a reasoned judgment whether to 
> accept the session or not.  The calling party can still refuse to send 
> Enhanced Calling Party Name Information or suppress the CLI for instance.
>
> service providers that issued the phone numbers to the parties is not 
> a bad place to start.  Last but not least .. we have no business 
> *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; 
> terminology so we can have a productive discussion and more 
> importantly to prevent any confusion.
>
> -CNAM is a term that the industry uses to refer to a terminating 
> service where the called party receives the name on an incoming call.  
> It is already used in Standards to refer to that terminating service.
>
> -The called party does NOT proactively seek or discover the name, as 
> "traceable" - again, only by the service provider, and not by the 
> agreement with the entity accessing your database, you have control 
> and you can take legal action if someone tries to "drain" your 
> database or cache data from it.
>
> -The other sources of "name" that are available online or otherwise, 
> should not be referred to as CNAM.  You may call them "name lookups" 
> or something else other than CNAM.
>
> useful. To start, I'll posit four:
>
> (1)/Traceable origin/: It must be clear to the recipient who vouches 
> for the information. (Assertion of the calling party? Some licensing 
> (2)/By value and/or by reference/: In the location context, we have 
> had long discussions about the trade-offs and I suspect we can learn 
> from that debate. By reference gives you easier scaling to large 
> (possibly
> (4)/Privacy/: The existing CNAM system has the disadvantage that 
> anybody can find out the name behind any number, rather than just the callee.
> http://800notes.com/, there may be ways to protect the interests of 
> both caller and callee that make systematic and large-scale collection 
> of reverse mappings more labor-intensive, particularly to protect the 
> The idea is pretty simple.  We all generally know what CNAM in the 
> PSTN is. (see below) Calling Name Delivery information is the verbose 
> ASCII text delivered to the User Agent in conjunction with the Caller 
> ID number of the calling party.  It is typically delivered as a 
> terminating service in SS7 via TCAP from LIDB databases.
>
> richer set of data displayed on their UA's and that can be delivered 
> by the SIP headers in some relatively simple form at session origination.
> Modification or a repurposing of the Call-Info header for instance 
> might be a simple way to start.  Incorporation of logos, pictures 
> whatever including presentation formats for STIR validation data etc.
>
> consumers having a richer set of information displayed on their 
> handsets in order to make more informed decisions on whether to accept the
> session.   "Is this really my bank calling me?"
>
> away and STIR, by itself, is no 'silver bullet'. I think we have all 
> understood that.
>
> party is what we are trying to protect here. In addition we do not 
> want to see the technique itself become a form of SPAM flooding UA's.
>
> managed.  We do not want to run down the rat hole of who determines 
> that this Bank or this Doctor is actually the one that creates the 
> data object.  That IMHO is someone else's problem.
>
> into some of these issues on an informal basis now in the review of 
> STIR progress etc. Obviously given the ongoing global launch of VoLTE 
> I'm willing to take a first cut at a Problem Statement and 
> Requirements so I'm looking for collaborators here.
>
> logical to confine the technical discussion there except for the 
> obvious DISPATCH issues etc expressions of interest support etc.
>
> cnit mailing list
>
> Integrated Services Digital Network (ISDN) - Calling Line 
> Identification Presentation and Restriction Supplementary Services, 
> ANSI T1.625-1993
>
> Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 
> 703.593.2683 <mailto:richard(at)shockey.us>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Aug 2014 11:30:10 -0400

Henning,

All the things you mention make sense, and may be factors in the 
solution. My point, to Richard, was that we can't just sweep *all* of 
this under the rug as "policy" issues to be addressed by somebody else. 
Certainly there needs to be room for applying policy, but ISTM there 
must be a framework with the policy decision points well identified.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Aug 2014 15:47:53 +0000

My main point was that it seems likely that for different kinds of useful information, different sources are likely to be authoritative, and any solution, as you say, should be flexible enough to allow for different sources.

The solution space isn't all that large, as far as I can tell. As a strawman, if you start with SIP Call-Info, you can picture one or more HTTP retrievals of a signed JSON object or an implicit signing by retrieving from a trusted HTTPS source. (For example, maybe there's a charity registry that the recipient trusts or a reference to Dun&Bradstreet or a Realtor licensing entity.) In that model, STIR cryptographically ties the assertions to the call request, but the validation of the actual information is done by the call recipient, and separately. You also have to make sure that the caller is authorized to link to a particular information object; we provided mechanism in the ARID proposal, but there are other options, e.g., through the phone number. (The recipient will only trust the information if that information contains the STIR-verified phone number in the property object.)

You can also do by-value (either in the body or the header) instead of by-reference, but that seems to require additional protocol standards work.

I would guess that the "whom do you trust" decision will be somewhat automated and delegated, rather than end users digging through X.509 certificates.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, August 21, 2014 11:30 AM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91

Henning,

All the things you mention make sense, and may be factors in the solution. My point, to Richard, was that we can't just sweep *all* of this under the rug as "policy" issues to be addressed by somebody else. 
Certainly there needs to be room for applying policy, but ISTM there must be a framework with the policy decision points well identified.

	Thanks,
	Paul

On 8/21/14 11:13 AM, Henning Schulzrinne wrote:
>> We meaning the stewards of SIP etc.  It is my strong preference, and 
>> I will try and insist on, keeping the focus of the work only on what 
>> that would probably be my friends at ATIS which works closely with 
>> the FCC and the CRTC in Canada or in the UK the NICC which performs a 
>> */Permit the rewriting of Call-Info header for carrier STIR 
>> validation text or something.  "Trusted by Vodafone" "Not Validated" 
>> Something in the INVITE to the UA that can be displayed. Which is why 
>> this is so important to VoLTE and the mobile handsets. In VoLTE the 
>> INVITE reaches the handset so yes it really is a issue for Apple and Android as well.
>> The minute you pose the architectural question of whether this is 
>> true peer-to-peer (aka a protocol independent of SIP),
>>
>> */[RS> ] IMHO this is not a business need, though there is certainly 
>> a business model to support the deployment of this.  What are we 
>> trying to do here?  You don't need me to explain that the contagion 
>> of Caller ID spoofing is driving consumers crazy and driving National 
>> Regulatory Authorities crazy as well.  I would argue that STIR and 
>> this effort is a perfectly reasonable Consumer Protection effort.  
>> That is honorable work we all could be proud of. /*
>>
>> *//*
>>
>> */Can't we make SIP safer for people to use?  I am not a regulator 
>> nor do I play one on TV but this IMHO is exactly the kind of thing we 
>> as technical professionals and the IETF .. (don't get me started on 
>> ISOC) should do.  It could be pretty simple stuff and it WILL have a 
>> We can call it what every you want.  Alas we don't have Hadrial 
>> Kaplan any more to dream up catchy names.
>>
>> running discussion of the policy questions associated with the 
>> service and the design implications.  I was trying to focus attention 
>> on to basic elements. One is the object itself that carries the more 
>> SIP and realtime communications are not email. We are not 
>> invalidating existing SIP privacy mechanisms only making sure that 
>> the called party has sufficient information to make a reasoned 
>> judgment whether to accept the session or not.  The calling party can 
>> still refuse to send Enhanced Calling Party Name Information or suppress the CLI for instance.
>>
>> accommodate different consumer needs (including supporting people 
>> with hearing or visual disabilities), along with robots that use the 
>> both caller and callee that make systematic and large-scale 
>> collection of reverse mappings more labor-intensive, particularly to 
>> protect the reasonable expectations of private individuals.
>>
>> Character ASCII.  No support for International characters etc.  It 
>> has not, to my knowledge, been widely deployed in mobile access networks.
>> It is not a hard stretch to postulate that called parties might like 
>> a richer set of data displayed on their UA's and that can be 
>> delivered by the SIP headers in some relatively simple form at session origination.
>> 3.How is STIR validation data delivered to the UA, presuming that 
>> STIR continues to progress.
>>
>> coordination with 3GPP here.  I have on good authority 3GPP is 
>> looking into some of these issues on an informal basis now in the 
>> review of STIR progress etc. Obviously given the ongoing global 
>> launch of VoLTE services this work should be of strong interest.
>>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 21 Aug 2014 13:37:42 -0400

Essentially yes.  Paul this is my point as well.  The solution space is not
that large.

 Its easy to postulate the rough outline of a solution here. The general
tools exist in some form already. In short this is not rocket science.

 If you dive too far into policy here it will become rocket science since it
will be impossible to cover every corner case we can devise and there are a
lot of them.  Which is why IMHO a charter here needs to be very very
carefully crafted to limit scope. That is the problem DISPATCH and the AD's
will have to confront at some point in time.

-----Original Message-----
From: cnit [mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Thursday, August 21, 2014 11:48 AM
To: 'Paul Kyzivat'; [email-masked]
Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition
at IETF 91

My main point was that it seems likely that for different kinds of useful
information, different sources are likely to be authoritative, and any
solution, as you say, should be flexible enough to allow for different
sources.

The solution space isn't all that large, as far as I can tell. As a
strawman, if you start with SIP Call-Info, you can picture one or more HTTP
retrievals of a signed JSON object or an implicit signing by retrieving from
a trusted HTTPS source. (For example, maybe there's a charity registry that
the recipient trusts or a reference to Dun&Bradstreet or a Realtor licensing
entity.) In that model, STIR cryptographically ties the assertions to the
call request, but the validation of the actual information is done by the
call recipient, and separately. You also have to make sure that the caller
is authorized to link to a particular information object; we provided
mechanism in the ARID proposal, 

[RS> ] ARID proposal??? 

but there are other options, e.g., through the phone number. (The recipient
will only trust the information if that information contains the
STIR-verified phone number in the property object.)

You can also do by-value (either in the body or the header) instead of
by-reference, but that seems to require additional protocol standards work.

I would guess that the "whom do you trust" decision will be somewhat
automated and delegated, rather than end users digging through X.509
certificates.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, August 21, 2014 11:30 AM
To: Henning Schulzrinne; [email-masked]
Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition
at IETF 91

Henning,

All the things you mention make sense, and may be factors in the solution.
My point, to Richard, was that we can't just sweep *all* of this under the
rug as "policy" issues to be addressed by somebody else. 
Certainly there needs to be room for applying policy, but ISTM there must be
a framework with the policy decision points well identified.

	Thanks,
	Paul

On 8/21/14 11:13 AM, Henning Schulzrinne wrote:
> (1) Physical address (for non-VoIP or facilities-based VoIP landlines):
Generally, if you trust the originating carrier, they know that information.
The address is often wrong or misleading for OTT VoIP or franchise-style
settings, where the address would reflect some corporate HQ or billing
address, not the caller's address.
>
> (2) Name of business or individual: Carriers will know the billing name,
but not if the account is pre-pay. Also, I suspect that they don't
necessarily track changes in business names (particularly DBAs) as long as
the bill gets paid. My guess is that even for post-pay, there are a fair
number of errors - somebody else paying the bill, marriage/divorce, name
changes, typos, ... For family wireless accounts, the account holder name is
shown (for carriers like TMo that provide this at all - most don't). When I
call somebody, it announces me as my wife's name.
>
> (3) Property assertion: The most interesting information is often what
kind of entity the caller is, e.g., whether the caller is actually a
state-registered charity or a real medical provider or a licensed chimney
sweep. The carrier won't have a clue today.
>
> One of the problems with the current system is that the caller itself has
no reliable way to find out what will be displayed to the callee, given that
the database dip is done by the terminating carrier. As one random example
of how things are changing, Google now offer a version of caller ID on
Android (https://support.google.com/nexus/answer/3459196?hl=en).
> I'm suspect that some of the policy decisions can be deferred as you
suggest, but I also suspect that there are architectural issues that affect
those policy issues.
make the trust decision on a case-by-case basis. But this is probably
impractical. Instead, it is likely that the callee's device will be making
the trust decision, and using it to make some policy decisions on behalf of
the callee: to accept/reject the call, to display Y or not, etc. How can it
make those decisions without some standards for whether to trust X or not?
> The "obvious" answer in the context of STIR is that I should trust X's
assertion of Y if I trust X's STIR assertion of the calling number. But that
doesn't seem like a good conclusion without some standards.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 Aug 2014 18:11:53 +0000

Since you asked about ARID, here's the link to the long-expired I-D:

http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00

It doesn't quite solve the same problem, particularly since it predates the STIR discussion.

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Thursday, August 21, 2014 1:38 PM
To: Henning Schulzrinne; 'Paul Kyzivat'; [email-masked]
Cc: [email-masked]
Subject: RE: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91

Essentially yes.  Paul this is my point as well.  The solution space is not that large.

 Its easy to postulate the rough outline of a solution here. The general tools exist in some form already. In short this is not rocket science.

 If you dive too far into policy here it will become rocket science since it will be impossible to cover every corner case we can devise and there are a lot of them.  Which is why IMHO a charter here needs to be very very carefully crafted to limit scope. That is the problem DISPATCH and the AD's will have to confront at some point in time.

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 23 Aug 2014 16:59:02 -0400

Hi Richard,

IMHO, it would be global industry standards bodies
like GSMA and 3GPP that would engage.  There is
also CableLabs, and for Europe, maybe E2NA.  Does
ATIS still exist? :-)

--tony

On 2014-08-20 9:10 PM, Richard Shockey wrote:
> would end up being part of some other SDO’s work.  In North America 
> technical experts to describe ‘Policy Considerations’ but beyond that 

-- 

________________________________ **

*Tony Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]> **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 27 Aug 2014 12:35:47 -0400

IETF and 3GPP to be sure but then there are national specific implementation
issues.  Yes ATIS. :)  NICC in the UK you know the drill.

Let the NRA's deal with policy.  That is my point.

On another issue that is totally irrelevant to the technical discussion,
there is no doubt in my mind there is a very strong business case for
enhancing calling party name display.  Especially for the mobile operators
and handset folks Apple Google/Android etc. 

From: cnit [mailto:[email-masked]] On Behalf Of Tony Rutkowski
Sent: Saturday, August 23, 2014 4:59 PM
To: Richard Shockey; 'Michael Hammer'; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT proposition
at IETF 91

Hi Richard,

--tony

-- 

Tony Rutkowski 

[email-masked]  <mailto:[email-masked]> 

Yaana Technologies LLC 

542 Gibraltar Drive 

Milpitas CA 95035 USA

---

From: Brian Rosen <[email-masked]>
Date: Thu, 28 Aug 2014 17:14:31 -0400

I certainly think it is time to rev up the cnit discussion.

On this subject, please do not forget that once you extend to richer expression methods, you introduce many more forms of mischief in portraying identity.    

We certainly must allow internationalized names, that’s not even up for debate.  But what else are you thinking that could really get messy quick.  For example, if you allow an image, then we have all sorts of issues like size, format, trojans, objectionable images, …

I’m not suggesting we shy away, but only that we be cautious, and plan for appropriate ways to control abuse.

Brian

On Aug 27, 2014, at 12:35 PM, Richard Shockey <[email-masked]> wrote:

> IETF and 3GPP to be sure but then there are national specific implementation issues.  Yes ATIS. J  NICC in the UK you know the drill.
>  
> Let the NRA’s deal with policy.  That is my point.
>  
> On another issue that is totally irrelevant to the technical discussion, there is no doubt in my mind there is a very strong business case for enhancing calling party name display.  Especially for the mobile operators and handset folks Apple Google/Android etc.
>  
> To: Richard Shockey; 'Michael Hammer'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT proposition at IETF 91
>  
> Hi Richard,
> 
> IMHO any reasonable deployment scenario for whatever we call this would end up being part of some other SDO’s work.  In North America that would probably be my friends at ATIS which works closely with the FCC and the CRTC in Canada or in the UK the NICC which performs a similar technical advisory function for OFCOM.  Would ETSI get involved for Europe as a whole.. Probably.  We are not there and nor should we go there.  Its perfectly reasonable for the IETF as technical experts to describe ‘Policy Considerations’ but beyond that we are out of our league.
>  
> --
> [email-masked]
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir