From nobody Mon Aug 18 10:19:33 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387591A03F2 for ; Mon, 18 Aug 2014 10:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTvkAbPRF_7I for ; Mon, 18 Aug 2014 10:19:26 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id B2C741A03D8 for ; Mon, 18 Aug 2014 10:19:26 -0700 (PDT) Received: (qmail 5663 invoked by uid 0); 18 Aug 2014 17:19:23 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy5.mail.unifiedlayer.com with SMTP; 18 Aug 2014 17:19:23 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id gNzG1o00R1MNPNq01NzKMU; Mon, 18 Aug 2014 16:59:22 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=V8ZMEJ5U9qYA:10 a=akrrgyzQK0cA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=U5xgfXdx548OpXhyOmMA:9 a=xt2hMd8-LY-INvJa:21 a=cIxHXPouaSmGyHkD:21 a=CjuIK1q_8ugA:10 a=ivbTfD_dPm4A:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a=emTtFift818A:10 a=NWVoK91CQyQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=MXl8fSyGdnhbVMFgEaIA:9 a=rZhqAo21_yYls17G:21 a=x-MzhDPzyOm2VLEs:21 a=mlaoQF8-cwP2vTAw:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:Cc:To:From; bh=BBk30K2o7TqXK8+2se76puls1LE2EXagkhavbSN99CY=; b=Ib74LpFgN6kiJZ0607l3zzPny6pHl236ydytI7c5OjLFSrWOzo/bnlVMEICmmERtMVnnkddkfpV12T7ng398fDMBFNMlGuYp5HW6krj0IQVH9k/sUJKtm/Mw/aamYWMl; Received: from [72.66.64.164] (port=50992 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XJQH7-00061E-Cv; Mon, 18 Aug 2014 10:59:17 -0600 From: "Richard Shockey" To: "'DISPATCH'" , Date: Mon, 18 Aug 2014 12:59:13 -0400 Message-ID: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01CFBAE4.3766FD80" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+6/n0ZwtZx5AWBTjuZF1votDRkSQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/JMFjPXgkAjwUwQlygI0KkezUcNM Cc: stir@ietf.org Subject: [cnit] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:19:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DC_01CFBAE4.3766FD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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 cnit@ietf.org 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> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_00DC_01CFBAE4.3766FD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

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

cnit@ietf.org

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>
skype= -linkedin-facebook: = rshockey101
http://www.sipforum.org

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

 

 

------=_NextPart_000_00DC_01CFBAE4.3766FD80-- From nobody Mon Aug 18 12:29:24 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA59B1A00AD; Mon, 18 Aug 2014 12:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRcOtOxTRxbl; Mon, 18 Aug 2014 12:29:14 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1CD1A00A8; Mon, 18 Aug 2014 12:29:13 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Richard Shockey' , 'DISPATCH' , "cnit@ietf.org" Thread-Topic: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: Ac+6/n0ZwtZx5AWBTjuZF1votDRkSQAGhWYw Date: Mon, 18 Aug 2014 19:29:12 +0000 References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> In-Reply-To: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046CB9C2Fp2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/SOe8xZw77aAsxNsLkmhBBNnm8oc Cc: "stir@ietf.org" Subject: Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 19:29:18 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046CB9C2Fp2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for re-starting the discussion. Before getting into the header detai= ls, 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 ca= rrier? Third-party database?) (2) By value and/or by reference: In the location context, we have had l= ong discussions about the trade-offs and I suspect we can learn from that d= ebate. By reference gives you easier scaling to large (possibly signed) obj= ects and differentiated access control. By value requires fewer moving part= s. Allowing for both may allow for trade-offs rather than endless arguments= . (3) Extensibility and rendering: Given the diversity of end systems, ran= ging from very small screens that are only suited for ASCII and text-to-spe= ech systems, to desktop displays, we want this to work reasonably well acro= ss the range of devices, and probably also accommodate different consumer n= eeds (including supporting people with hearing or visual disabilities), alo= ng with robots that use the information to make call routing and call handl= ing 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 la= bor-intensive, particularly to protect the reasonable expectations of priva= te individuals. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91 I have reason to believe it may be useful to revisit the CNAM CNIT proposit= ion during DISPATCH at 91 and see if there is consensus on moving forward o= n 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 de= livered to the User Agent in conjunction with the Caller ID number of the c= alling party. It is typically delivered as a terminating service in SS7 vi= a 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 kn= owledge, 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 rich= er 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. Modificatio= n or a repurposing of the Call-Info header for instance might be a simple w= ay to start. Incorporation of logos, pictures whatever including presentat= ion formats for STIR validation data etc. Creation and transmission is fully governed by existing SIP privacy mechani= sms. Display at termination is governed by UA or service provider policy. There is every reason to National Regulators would be delighted with consu= mers having a richer set of information displayed on their handsets in orde= r to make more informed decisions on whether to accept the session. "Is t= his 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 an= d STIR, by itself, is no 'silver bullet'. I think we have all understood th= at. There are some interesting aspects of this. There are clearly privacy consi= derations however I would argue that the privacy of the called party is wha= t we are trying to protect here. In addition we do not want to see the tech= nique itself become a form of SPAM flooding UA's. What I would propose is a Charter of very very narrow scope. MARTINI as th= e model. 1. What SIP header would carry the CNAM Plus object? 2. What would a CNAM Plus object look like? JSON 3. How is STIR validation data delivered to the UA, presuming that STI= R continues to progress. I would rule out of scope any discussion of how the data in the CNAM Plus o= bject is created, stored, or how its origin is determined or managed. We d= o not want to run down the rat hole of who determines that this Bank or thi= s Doctor is actually the one that creates the data object. That IMHO is so= meone 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 the= se issues on an informal basis now in the review of STIR progress etc. Obvi= ously 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 t= o confine the technical discussion there except for the obvious DISPATCH is= sues etc expressions of interest support etc. cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit Thoughts? ****************** American National Standards Institute (ANSI), Telecommunications Network-to= -Customer Installation Interfaces - Analog Voice grade Switched Access Lin= es with Calling Number Delivery, Calling Name Delivery, or Visual Message-W= aiting Indicator Features, ANSI T1.6401.03-1998 American National Standards Institute (ANSI), Telecommunications- Integrate= d Services Digital Network (ISDN) - Calling Line Identification Presentatio= n and Restriction Supplementary Services, ANSI T1.625-1993 American National Standards Institute ANSI), Telecommunications - Calling N= ame Identification Presentation, ANSI T1.641-1995 Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requi= rements", GR-1188-CORE, Issue 2, December 2000 Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-COR= E, 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 skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm --_000_E6A16181E5FD2F46B962315BB05962D046CB9C2Fp2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for re-starting= the discussion. Before getting into the header details, having a clearer u= nderstanding of the requirements would be useful. To start, I’ll posi= t four:

 

(1)&= nbsp;   Traceable o= rigin: It must be clear to the rec= ipient who vouches for the information. (Assertion of the calling party? So= me licensing authority such as a financial regulator or a professional association? Originating carrier? Third-party = database?)

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

(3)&= nbsp;   Extensibili= ty and rendering: Given the divers= ity of end systems, ranging from very small screens that are only suited fo= r 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 (includ= ing supporting people with hearing or visual disabilities), along with robo= ts that use the information to make call routing and call handling decisions.

(4)&= nbsp;   Privacy: The existing CNAM system has the dis= advantage 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 ht= tp://800notes.com/, there may be ways to protect the interests of both = caller and callee that make systematic and large-scale collection of revers= e mappings more labor-intensive, particularly to protect the reasonable expectations of private individuals. =

 

From: stir [ma= ilto:stir-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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 consen= sus on moving forward on some level of standardization here.

 

The idea is pretty simple.  We all generally kn= ow 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 t= he Caller ID number of the calling party.  It is typically delivered as a terminating service in SS7 via TCAP from LI= DB databases.

 

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

 

It is not a hard stretch to postulate that called pa= rties 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 o= rigination. 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 f= or STIR validation data etc.

 

Creation and transmission is fully governed by exist= ing SIP privacy mechanisms.

 

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

 

There is every reason to  National Regulators w= ould be delighted with consumers having a richer set of information display= ed 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 spoo= fing problem has not gone away and STIR, by itself, is no ‘silver bul= let’. I think we have all understood that.

 

There are some interesting aspects of this. There ar= e 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 n= ot want to see the technique itself become a form of SPAM flooding UA’s.

 

What I would propose is a Charter of very very narro= w 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 deter= mined or managed.  We do not want to run down the rat hole of who dete= rmines 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 revie= w 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 S= tatement and Requirements so I’m looking for collaborators here.

 

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

 

cnit mailing list

cnit@ietf.org

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

 

Thoughts?

 

 

 

 

 

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

 

American National Standards Institute (ANSI), Teleco= mmunications Network-to-Customer Installation Interfaces - Analog Voice gra= de  Switched Access Lines with Calling Number Delivery, Calling Name D= elivery, or Visual Message-Waiting Indicator Features, ANSI  T1.6401.03-1998

 

American National Standards Institute (ANSI), Teleco= mmunications- Integrated Services Digital Network (ISDN) - Calling Line Ide= ntification Presentation and Restriction Supplementary Services, ANSI T1.62= 5-1993

 

American National Standards Institute ANSI), Telecom= munications - 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<= /a>
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mai= lto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http://www.sipforum.org<= /span>

"Money is the answer, what is the question?" t= m

 

 

--_000_E6A16181E5FD2F46B962315BB05962D046CB9C2Fp2pxmb13fccnetw_-- From nobody Mon Aug 18 21:50:49 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568D21A87DD; Mon, 18 Aug 2014 21:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov6B_LWCYUpJ; Mon, 18 Aug 2014 21:50:43 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF711A87DC; Mon, 18 Aug 2014 21:50:42 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-32-53f283442e63 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F1.2F.05330.44382F35; Tue, 19 Aug 2014 00:50:44 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 19 Aug 2014 00:50:33 -0400 From: Hala Mowafy To: Henning Schulzrinne , 'Richard Shockey' , 'DISPATCH' , "cnit@ietf.org" Thread-Topic: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPuxq8aLQghJL4fES3fTwwrTuV7pvXVGhw Date: Tue, 19 Aug 2014 04:50:32 +0000 Message-ID: <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_728F35AE98AEDB4A96FF3A32A85A60BB394D808Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHT9el+VOwQcNWQ4urs/cxWiydtIDV 4ueR3awWM34YWCxfu43JgdXj9u03bB5Llvxk8pj48QxzAHMUl01Kak5mWWqRvl0CV8bvj0dY C5Z0MFU0Ti9tYFz6hLGLkYNDQsBEonO3ehcjJ5ApJnHh3nq2LkYuDiGBo4wSh7Y0s0M4yxkl Hsy+ywZSxSagIzHn70dmkISIwCJGiblvzrGATGIWUJb4t9sepEZYwFni843dLCC2iICLxLxP c5lBSkQEjCSmttqAhFkEVCV27JjMCmLzCvhKXPn8E8wWEsiV+PX8PROIzSlgL9H7ZSXYGEag 476fWgMWZxYQl7j1ZD4TxNECEkv2nGeGsEUlXj7+xwphK0l8/D2fHaI+X2LBp042iF2CEidn PmGZwCg6C8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYOUqLU8ty040M NjECY++YBJvuDsY9Ly0PMQpwMCrx8C449zFYiDWxrLgy9xCjNAeLkjjvrNp5wUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYN3c16po5NVb63RdYmSEyYVez8KyXeeW9O/s8RAu+3vrV+uRG dphU2JYTBTJrrW2tkjTfegl9DnCtz/mzQf3+SU3jlVuXBPoLrve60fzXVSHUXPTHjRSVHqFp lV82veSsPHncv7fgepJ2m8HN6ADbfKOtLfWxnd2CXh1/Dh3LWV/lo/I1QU2JpTgj0VCLuag4 EQDio04DngIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/MJHI8GfitEegO2dPDyRP6euvgnE Cc: "stir@ietf.org" Subject: Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 04:50:47 -0000 --_000_728F35AE98AEDB4A96FF3A32A85A60BB394D808Feusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Before we go any further on discussing CNAM, we need to clarify the termino= logy 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 se= rvice 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, a= s in a Google look up. Name is delivered to them. - Called party has no choice over the source, e.g., which database t= o query for the name. For most CNAM offerings, the service provider choose= s that database. - In the CNAM service model, since the service provider has business= agreements with the database owner, the name would be considered "traceabl= e" - 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 acc= essing your database, you have control and you can take legal action if som= eone 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 s= omething else other than CNAM. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thanks for re-starting the discussion. Before getting into the header detai= ls, 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 ca= rrier? Third-party database?) (2) By value and/or by reference: In the location context, we have had l= ong discussions about the trade-offs and I suspect we can learn from that d= ebate. By reference gives you easier scaling to large (possibly signed) obj= ects and differentiated access control. By value requires fewer moving part= s. Allowing for both may allow for trade-offs rather than endless arguments= . (3) Extensibility and rendering: Given the diversity of end systems, ran= ging from very small screens that are only suited for ASCII and text-to-spe= ech systems, to desktop displays, we want this to work reasonably well acro= ss the range of devices, and probably also accommodate different consumer n= eeds (including supporting people with hearing or visual disabilities), alo= ng with robots that use the information to make call routing and call handl= ing 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 la= bor-intensive, particularly to protect the reasonable expectations of priva= te individuals. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91 I have reason to believe it may be useful to revisit the CNAM CNIT proposit= ion during DISPATCH at 91 and see if there is consensus on moving forward o= n 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 de= livered to the User Agent in conjunction with the Caller ID number of the c= alling party. It is typically delivered as a terminating service in SS7 vi= a 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 kn= owledge, 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 rich= er 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. Modificatio= n or a repurposing of the Call-Info header for instance might be a simple w= ay to start. Incorporation of logos, pictures whatever including presentat= ion formats for STIR validation data etc. Creation and transmission is fully governed by existing SIP privacy mechani= sms. Display at termination is governed by UA or service provider policy. There is every reason to National Regulators would be delighted with consu= mers having a richer set of information displayed on their handsets in orde= r to make more informed decisions on whether to accept the session. "Is t= his 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 an= d STIR, by itself, is no 'silver bullet'. I think we have all understood th= at. There are some interesting aspects of this. There are clearly privacy consi= derations however I would argue that the privacy of the called party is wha= t we are trying to protect here. In addition we do not want to see the tech= nique itself become a form of SPAM flooding UA's. What I would propose is a Charter of very very narrow scope. MARTINI as th= e model. 1. What SIP header would carry the CNAM Plus object? 2. What would a CNAM Plus object look like? JSON 3. How is STIR validation data delivered to the UA, presuming that STI= R continues to progress. I would rule out of scope any discussion of how the data in the CNAM Plus o= bject is created, stored, or how its origin is determined or managed. We d= o not want to run down the rat hole of who determines that this Bank or thi= s Doctor is actually the one that creates the data object. That IMHO is so= meone 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 the= se issues on an informal basis now in the review of STIR progress etc. Obvi= ously 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 t= o confine the technical discussion there except for the obvious DISPATCH is= sues etc expressions of interest support etc. cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit Thoughts? ****************** American National Standards Institute (ANSI), Telecommunications Network-to= -Customer Installation Interfaces - Analog Voice grade Switched Access Lin= es with Calling Number Delivery, Calling Name Delivery, or Visual Message-W= aiting Indicator Features, ANSI T1.6401.03-1998 American National Standards Institute (ANSI), Telecommunications- Integrate= d Services Digital Network (ISDN) - Calling Line Identification Presentatio= n and Restriction Supplementary Services, ANSI T1.625-1993 American National Standards Institute ANSI), Telecommunications - Calling N= ame Identification Presentation, ANSI T1.641-1995 Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requi= rements", GR-1188-CORE, Issue 2, December 2000 Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-COR= E, 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 skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm --_000_728F35AE98AEDB4A96FF3A32A85A60BB394D808Feusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

-     &= nbsp;  CNAM is a term that the industry uses to refer to a= terminating service where the called party receives the name on an incomin= g call.  It is already used in Standards to refer to that terminating = service.

-     &= nbsp;  The called party does NOT proactively seek or disco= ver the name, as in a Google look up.  Name is delivered to them.=

-     &= nbsp;  Called party has no choice over the source, e.g., w= hich database to query for the name.  For most CNAM offerings, the ser= vice provider chooses that database.

-     &= nbsp;  In the CNAM service model, since the service provid= er has business agreements with the database owner, the name would be consi= dered “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 datab= ase, you have control and you can take legal action if someone tries to = 220;drain” your database or cache data from it. 

-     &= nbsp;  The other sources of “name” that are av= ailable online or otherwise, should not be referred to as CNAM.  You m= ay call them “name lookups” or something else other than CNAM.<= o:p>

 

From: stir [ma= ilto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Monday, August 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91<= o:p>

 

Thanks for re-starting= the discussion. Before getting into the header details, having a clearer u= nderstanding of the requirements would be useful. To start, I’ll posi= t four:

 

(1)&= nbsp;   Traceable o= rigin: It must be clear to the rec= ipient who vouches for the information. (Assertion of the calling party? So= me licensing authority such as a financial regulator or a professional association? Originating carrier? Third-party = database?)

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

(3)&= nbsp;   Extensibili= ty and rendering: Given the divers= ity of end systems, ranging from very small screens that are only suited fo= r 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 (includ= ing supporting people with hearing or visual disabilities), along with robo= ts that use the information to make call routing and call handling decisions.

(4)&= nbsp;   Privacy: The existing CNAM system has the dis= advantage 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 ht= tp://800notes.com/, there may be ways to protect the interests of both = caller and callee that make systematic and large-scale collection of revers= e mappings more labor-intensive, particularly to protect the reasonable expectations of private individuals. =

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org
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 consen= sus on moving forward on some level of standardization here.

 

The idea is pretty simple.  We all generally kn= ow 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 t= he Caller ID number of the calling party.  It is typically delivered as a terminating service in SS7 via TCAP from LI= DB databases.

 

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

 

It is not a hard stretch to postulate that called pa= rties 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 o= rigination. 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 f= or STIR validation data etc.

 

Creation and transmission is fully governed by exist= ing SIP privacy mechanisms.

 

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

 

There is every reason to  National Regulators w= ould be delighted with consumers having a richer set of information display= ed 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 spoo= fing problem has not gone away and STIR, by itself, is no ‘silver bul= let’. I think we have all understood that.

 

There are some interesting aspects of this. There ar= e 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 n= ot want to see the technique itself become a form of SPAM flooding UA’s.

 

What I would propose is a Charter of very very narro= w 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 deter= mined or managed.  We do not want to run down the rat hole of who dete= rmines 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 revie= w 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 S= tatement and Requirements so I’m looking for collaborators here.

 

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

 

cnit mailing list

cnit@ietf.org

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

 

Thoughts?

 

 

 

 

 

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

 

American National Standards Institute (ANSI), Teleco= mmunications Network-to-Customer Installation Interfaces - Analog Voice gra= de  Switched Access Lines with Calling Number Delivery, Calling Name D= elivery, or Visual Message-Waiting Indicator Features, ANSI  T1.6401.03-1998

 

American National Standards Institute (ANSI), Teleco= mmunications- Integrated Services Digital Network (ISDN) - Calling Line Ide= ntification Presentation and Restriction Supplementary Services, ANSI T1.62= 5-1993

 

American National Standards Institute ANSI), Telecom= munications - 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<= /a>
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mai= lto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http://www.sipforum.org<= /span>

"Money is the answer, what is the question?" t= m

 

 

--_000_728F35AE98AEDB4A96FF3A32A85A60BB394D808Feusaamb105erics_-- From nobody Wed Aug 20 11:46:11 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F091A069B; Wed, 20 Aug 2014 11:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLcDislMXzQ1; Wed, 20 Aug 2014 11:46:02 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id A57901A064A; Wed, 20 Aug 2014 11:46:00 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Hala Mowafy' , 'Richard Shockey' , 'DISPATCH' , "cnit@ietf.org" Thread-Topic: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: Ac+6/n0ZwtZx5AWBTjuZF1votDRkSQAGhWYwAByD5wAARtfssA== Date: Wed, 20 Aug 2014 18:45:58 +0000 References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> In-Reply-To: <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E6A16181E5FD2F46B962315BB05962D046CC28A0p2pxmb13fccnetw_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/tdDrHuYsUKifxTqPgMJfVOiCJ5M Cc: "stir@ietf.org" Subject: Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:46:08 -0000 --_000_E6A16181E5FD2F46B962315BB05962D046CC28A0p2pxmb13fccnetw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hala, I don't think we're disagreeing, but if anything I said is at odds with you= r description, please say so. I was referring to the many services that pro= vide an API-based service that appears to rely on the same databases for ca= ller name delivery. At least for many telecom service providers, they seem to draw on multiple = LIDB providers, including sometimes configure-your-own-message services lik= e 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 produc= tive to get into how a legacy service is defined, maybe "textual callerID" = is the better term. Henning From: Hala Mowafy [mailto:hala.mowafy@ericsson.com] Sent: Tuesday, August 19, 2014 12:51 AM To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91 Before we go any further on discussing CNAM, we need to clarify the termino= logy 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 i= s 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 choo= ses that database. - In the CNAM service model, since the service provider has busine= ss agreements with the database owner, the name would be considered "tracea= ble" - again, only by the service provider, and not by the calling or calle= d parties. If you, the database owner, have an agreement with the entity a= ccessing your database, you have control and you can take legal action if s= omeone tries to "drain" your database or cache data from it. - The other sources of "name" that are available online or otherwi= se, should not be referred to as CNAM. You may call them "name lookups" or= something else other than CNAM. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thanks for re-starting the discussion. Before getting into the header detai= ls, 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 ca= rrier? Third-party database?) (2) By value and/or by reference: In the location context, we have had l= ong discussions about the trade-offs and I suspect we can learn from that d= ebate. By reference gives you easier scaling to large (possibly signed) obj= ects and differentiated access control. By value requires fewer moving part= s. Allowing for both may allow for trade-offs rather than endless arguments= . (3) Extensibility and rendering: Given the diversity of end systems, ran= ging from very small screens that are only suited for ASCII and text-to-spe= ech systems, to desktop displays, we want this to work reasonably well acro= ss the range of devices, and probably also accommodate different consumer n= eeds (including supporting people with hearing or visual disabilities), alo= ng with robots that use the information to make call routing and call handl= ing 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 la= bor-intensive, particularly to protect the reasonable expectations of priva= te individuals. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91 I have reason to believe it may be useful to revisit the CNAM CNIT proposit= ion during DISPATCH at 91 and see if there is consensus on moving forward o= n 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 de= livered to the User Agent in conjunction with the Caller ID number of the c= alling party. It is typically delivered as a terminating service in SS7 vi= a 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 kn= owledge, 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 rich= er 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. Modificatio= n or a repurposing of the Call-Info header for instance might be a simple w= ay to start. Incorporation of logos, pictures whatever including presentat= ion formats for STIR validation data etc. Creation and transmission is fully governed by existing SIP privacy mechani= sms. Display at termination is governed by UA or service provider policy. There is every reason to National Regulators would be delighted with consu= mers having a richer set of information displayed on their handsets in orde= r to make more informed decisions on whether to accept the session. "Is t= his 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 an= d STIR, by itself, is no 'silver bullet'. I think we have all understood th= at. There are some interesting aspects of this. There are clearly privacy consi= derations however I would argue that the privacy of the called party is wha= t we are trying to protect here. In addition we do not want to see the tech= nique itself become a form of SPAM flooding UA's. What I would propose is a Charter of very very narrow scope. MARTINI as th= e model. 1. What SIP header would carry the CNAM Plus object? 2. What would a CNAM Plus object look like? JSON 3. How is STIR validation data delivered to the UA, presuming that STI= R continues to progress. I would rule out of scope any discussion of how the data in the CNAM Plus o= bject is created, stored, or how its origin is determined or managed. We d= o not want to run down the rat hole of who determines that this Bank or thi= s Doctor is actually the one that creates the data object. That IMHO is so= meone 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 the= se issues on an informal basis now in the review of STIR progress etc. Obvi= ously 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 t= o confine the technical discussion there except for the obvious DISPATCH is= sues etc expressions of interest support etc. cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit Thoughts? ****************** American National Standards Institute (ANSI), Telecommunications Network-to= -Customer Installation Interfaces - Analog Voice grade Switched Access Lin= es with Calling Number Delivery, Calling Name Delivery, or Visual Message-W= aiting Indicator Features, ANSI T1.6401.03-1998 American National Standards Institute (ANSI), Telecommunications- Integrate= d Services Digital Network (ISDN) - Calling Line Identification Presentatio= n and Restriction Supplementary Services, ANSI T1.625-1993 American National Standards Institute ANSI), Telecommunications - Calling N= ame Identification Presentation, ANSI T1.641-1995 Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requi= rements", GR-1188-CORE, Issue 2, December 2000 Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-COR= E, 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 skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm --_000_E6A16181E5FD2F46B962315BB05962D046CC28A0p2pxmb13fccnetw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hala,

 

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

 

At least for many tele= com service providers, they seem to draw on multiple LIDB providers, includ= ing 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 co= nfusion and since it doesn’t seem particularly productive to get into= how a legacy service is defined, maybe “textual callerID” is t= he better term.

 

Henning

 

From: Hala Mow= afy [mailto:hala.mowafy@ericsson.com]
Sent: Tuesday, August 19, 2014 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.or= g
Cc: stir@ietf.org
Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91<= o:p>

 

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

-     &= nbsp;    CNAM is a term that the industry uses to refer to a= terminating service where the called party receives the name on an incomin= g call.  It is already used in Standards to refer to that terminating = service.

-     &= nbsp;    The called party does NOT proactively seek or disco= ver the name, as in a Google look up.  Name is delivered to them.=

-     &= nbsp;    Called party has no choice over the source, e.g., w= hich database to query for the name.  For most CNAM offerings, the ser= vice provider chooses that database.

-     &= nbsp;    In the CNAM service model, since the service provid= er has business agreements with the database owner, the name would be consi= dered “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 datab= ase, you have control and you can take legal action if someone tries to = 220;drain” your database or cache data from it. 

-     &= nbsp;    The other sources of “name” that are av= ailable online or otherwise, should not be referred to as CNAM.  You m= ay call them “name lookups” or something else other than CNAM.<= o:p>

 

From: stir [mailto:stir-bounces@ietf= .org] On Behalf Of Henning Schulzrinne
Sent: Monday, August 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; = cnit@ietf.org
Cc: stir@ietf.org
Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91<= o:p>

 

Thanks for re-starting= the discussion. Before getting into the header details, having a clearer u= nderstanding of the requirements would be useful. To start, I’ll posi= t four:

 

(1)&= nbsp;   Traceable o= rigin: It must be clear to the rec= ipient who vouches for the information. (Assertion of the calling party? So= me licensing authority such as a financial regulator or a professional association? Originating carrier? Third-party = database?)

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

(3)&= nbsp;   Extensibili= ty and rendering: Given the divers= ity of end systems, ranging from very small screens that are only suited fo= r 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 (includ= ing supporting people with hearing or visual disabilities), along with robo= ts that use the information to make call routing and call handling decisions.

(4)&= nbsp;   Privacy: The existing CNAM system has the dis= advantage 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 ht= tp://800notes.com/, there may be ways to protect the interests of both = caller and callee that make systematic and large-scale collection of revers= e mappings more labor-intensive, particularly to protect the reasonable expectations of private individuals. =

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org
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 consen= sus on moving forward on some level of standardization here.

 

The idea is pretty simple.  We all generally kn= ow 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 t= he Caller ID number of the calling party.  It is typically delivered as a terminating service in SS7 via TCAP from LI= DB databases.

 

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

 

It is not a hard stretch to postulate that called pa= rties 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 o= rigination. 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 f= or STIR validation data etc.

 

Creation and transmission is fully governed by exist= ing SIP privacy mechanisms.

 

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

 

There is every reason to  National Regulators w= ould be delighted with consumers having a richer set of information display= ed 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 spoo= fing problem has not gone away and STIR, by itself, is no ‘silver bul= let’. I think we have all understood that.

 

There are some interesting aspects of this. There ar= e 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 n= ot want to see the technique itself become a form of SPAM flooding UA’s.

 

What I would propose is a Charter of very very narro= w 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 deter= mined or managed.  We do not want to run down the rat hole of who dete= rmines 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 revie= w 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 S= tatement and Requirements so I’m looking for collaborators here.

 

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

 

cnit mailing list

cnit@ietf.org

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

 

Thoughts?

 

 

 

 

 

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

 

American National Standards Institute (ANSI), Teleco= mmunications Network-to-Customer Installation Interfaces - Analog Voice gra= de  Switched Access Lines with Calling Number Delivery, Calling Name D= elivery, or Visual Message-Waiting Indicator Features, ANSI  T1.6401.03-1998

 

American National Standards Institute (ANSI), Teleco= mmunications- Integrated Services Digital Network (ISDN) - Calling Line Ide= ntification Presentation and Restriction Supplementary Services, ANSI T1.62= 5-1993

 

American National Standards Institute ANSI), Telecom= munications - 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<= /a>
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mai= lto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http://www.sipforum.org<= /span>

"Money is the answer, what is the question?" t= m

 

 

--_000_E6A16181E5FD2F46B962315BB05962D046CC28A0p2pxmb13fccnetw_-- From nobody Wed Aug 20 12:30:21 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F01A872F for ; Wed, 20 Aug 2014 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UlO3oC7myyQ for ; Wed, 20 Aug 2014 12:30:15 -0700 (PDT) Received: from qproxy2-pub.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id A25121A6F41 for ; Wed, 20 Aug 2014 12:30:10 -0700 (PDT) Received: (qmail 9464 invoked by uid 0); 20 Aug 2014 19:30:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 20 Aug 2014 19:30:05 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id hD9y1o00v1MNPNq01DA1GG; Wed, 20 Aug 2014 19:10:04 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=d_wBf3h3nX0A:10 a=JTwz1mGWTYQA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=r3bLr36jAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=MJBoXLuG5-sYhfOiGJAA:9 a=P-l8ExtPsBw30yL8:21 a=aV64KZIqtViDBmgZ:21 a=CjuIK1q_8ugA:10 a=ivbTfD_dPm4A:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a=emTtFift818A:10 a=NWVoK91CQyQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=KNkzjGwnPXndhiaot7YA:9 a=q5oHalYDUIGnOYGW:21 a=Lub_aZbgF_FE_X8V:21 a=CY_7gRVgA6iB-RzE:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=dFhrnvszwxtUuPN1EHwI6VHlkMI6eJo+z+s3KQlG6+Y=; b=JQDkuIPMa+U5Hv+hsLR3EbfTpM0ZLy3E0zOo31HdPk309ZWRnsKp4OVyQmbS1/j241SwWHEwl4a2EgeN7tC1I3N6MlhcFwYww5FNTBA9JQ+3nSvgu6speyQZ33lSSYc5; Received: from [72.66.64.164] (port=50401 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKBGh-0008PH-Qt; Wed, 20 Aug 2014 13:10:00 -0600 From: "Richard Shockey" To: "'Hala Mowafy'" , "'Henning Schulzrinne'" , "'DISPATCH'" , References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> In-Reply-To: <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> Date: Wed, 20 Aug 2014 15:09:55 -0400 Message-ID: <010601cfbcaa$55be97d0$013bc770$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0107_01CFBC88.CEB11680" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK+CaJT9Gl0BGzxyNJg2fKi/ufaXQKF81MWAdPt8M+Z2mS5UA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/fjtxmW7BsZMaDFnLcBWzXlIF0ak Cc: stir@ietf.org Subject: Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:30:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0107_01CFBC88.CEB11680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:cnit-bounces@ietf.org] On Behalf Of Hala Mowafy Sent: Tuesday, August 19, 2014 12:51 AM To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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. 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 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 cnit@ietf.org 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> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_0107_01CFBC88.CEB11680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:cnit-bounces@ietf.org] On Behalf Of Hala = Mowafy
Sent: Tuesday, August 19, 2014 12:51 AM
To: = Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; = cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Henning Schulzrinne
Sent: Monday, August = 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Richard Shockey
Sent: Monday, August 18, = 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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. =

 

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

cnit@ietf.org

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>
skype= -linkedin-facebook: rshockey101
http://www.sipforum.org

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

 

 

------=_NextPart_000_0107_01CFBC88.CEB11680-- From nobody Wed Aug 20 14:45:48 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C111A6EFB; Wed, 20 Aug 2014 14:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp-iLfwjd5Iw; Wed, 20 Aug 2014 14:45:33 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7481A6F0C; Wed, 20 Aug 2014 14:45:33 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 20 Aug 2014 14:44:51 -0700 From: Michael Hammer To: "richard@shockey.us" , "hala.mowafy@ericsson.com" , "Henning.Schulzrinne@fcc.gov" , "dispatch@ietf.org" , "cnit@ietf.org" Thread-Topic: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPvK0Wx9hBBz9nbUeH4A7JSWEZc5vaBUJA Date: Wed, 20 Aug 2014 21:44:51 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> In-Reply-To: <010601cfbcaa$55be97d0$013bc770$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.136] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_01D3_01CFBC9E.70D02EA0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/UBusWhR4E3jWP62qitdf-H8nU84 Cc: "stir@ietf.org" Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:45:38 -0000 ------=_NextPart_000_01D3_01CFBC9E.70D02EA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01D4_01CFBC9E.70D02EA0" ------=_NextPart_001_01D4_01CFBC9E.70D02EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, August 20, 2014 3:10 PM To: 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 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:cnit-bounces@ietf.org] On Behalf Of Hala Mowafy Sent: Tuesday, August 19, 2014 12:51 AM To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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. 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 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 cnit@ietf.org 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> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_001_01D4_01CFBC9E.70D02EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 = USA

www.yaanatech.com

 

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

 

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:cnit-bounces@ietf.org] = On Behalf Of Hala Mowafy
Sent: Tuesday, August 19, 2014 = 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; = 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Henning Schulzrinne
Sent: Monday, August = 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Richard Shockey
Sent: Monday, August 18, = 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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. =

 

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

cnit@ietf.org

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>
skype= -linkedin-facebook: rshockey101
http://www.sipforum.org

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

 

 

------=_NextPart_001_01D4_01CFBC9E.70D02EA0-- ------=_NextPart_000_01D3_01CFBC9E.70D02EA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE+zCCBPcCAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAvEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwODIwMjE0NDUwWjAjBgkqhkiG 9w0BCQQxFgQUVEnGgO17o9uhe9aA7ovBTxoXTCowgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZI AWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTEL MAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1h bnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJt ZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcN AQkQAgsxgeGggd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZ UHovRnYwDQYJKoZIhvcNAQEBBQAEggEAZlqrvaC6epvh4mWzz48dw4LLIFTFze8D8+nK3jOKmEsT lilAlLmaUjUXvGygEE/nagCpQ8btNtrAcf69EnQ/JRWiPSi5hty/jPcaltLZ8x1aiBLrVl811WZR M1bvZPhMZ3J/P/lJBU4B0nObYKtq6tjt3qP7mZ9k/1RFnAps/K3lRUegXRiIcDdqXPBWQJb5zqfR XE8oA4IFn4EW2XycHfaEfhaovsUd+YXToedo9xfiMchR8t0y2kK4/e1GuvqewJcLM/XDcxGbIdVn ocFAlrpqOjNr2gNWYyl6CJGiBz/mG0iDfCBCAx/z4v1DM0lAXXZmO3FP/kO7u0FRh07JQAAAAAAA AA== ------=_NextPart_000_01D3_01CFBC9E.70D02EA0-- From nobody Wed Aug 20 18:30:39 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0E1A0099 for ; Wed, 20 Aug 2014 18:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8ujNfwcu7vd for ; Wed, 20 Aug 2014 18:30:33 -0700 (PDT) Received: from qproxy2-pub.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id C76BB1A0073 for ; Wed, 20 Aug 2014 18:30:32 -0700 (PDT) Received: (qmail 6404 invoked by uid 0); 21 Aug 2014 01:30:25 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 21 Aug 2014 01:30:25 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id hDAF1o00K1MNPNq01DAJeJ; Wed, 20 Aug 2014 19:10:24 -0600 X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=QhHMBIAFjv8A:10 a=0Q47nzWvVFEA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=r3bLr36jAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AI0-pE7ExS0E72re3A8A:9 a=sPkRIQtulgRG1n4C:21 a=0M7-VpTwiYvQHJI6:21 a=CjuIK1q_8ugA:10 a=_Fszbdv8evYA:10 a=ivbTfD_dPm4A:10 a=E7MB4TUEIZIA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 a=emTtFift818A:10 a=NWVoK91CQyQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=6glFhHKhgQKbZzN88XwA:9 a=nLz6j1I433A6WugL:21 a=qiMsOguFT6z0KOEK:21 a=Pg-zQJHQbgYH7I2i:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=5cZgrYMZZyryrcDyzbbT/Hd8w69zsrwhk/urAWZWLPI=; b=POTFjaOpX4joQVKfAzsN/0C8Uk6zqZC+B05CjM5FoEB2R2uEEMbsUZeRsl7IrpqB5bnZ9VXLnIolgudx1BvCNPn6kJxnTxo3rwg1Tf52QlT2pf1IoFgFEpKPCmmI99ws; Received: from [72.66.64.164] (port=53910 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKGtL-0006hT-Op; Wed, 20 Aug 2014 19:10:16 -0600 From: "Richard Shockey" To: "'Michael Hammer'" , , , , References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> Date: Wed, 20 Aug 2014 21:10:10 -0400 Message-ID: <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01CFBCBB.22BA1380" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK+CaJT9Gl0BGzxyNJg2fKi/ufaXQKF81MWAdPt8M8Cfny6QgFoB149mbuXIeA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/4nEUC-k_XLkRuCB39QDBpDiQ9bg Cc: stir@ietf.org Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 01:30:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D9_01CFBCBB.22BA1380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard, I doubt you can avoid policy and business models. [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. 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. [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. If there were no business need, then no one would need this work. [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 michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, August 20, 2014 3:10 PM To: 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 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:cnit-bounces@ietf.org] On Behalf Of Hala Mowafy Sent: Tuesday, August 19, 2014 12:51 AM To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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. 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 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 cnit@ietf.org 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> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_01D9_01CFBCBB.22BA1380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Richard,

 

I doubt you can avoid = policy and business models.

 

[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/rf= c7095

 

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

 

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.

 

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

 

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

 

[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

michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 = USA

www.yaanatech.com

 

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

 

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:cnit-bounces@ietf.org] = On Behalf Of Hala Mowafy
Sent: Tuesday, August 19, 2014 = 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; = 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Henning Schulzrinne
Sent: Monday, August = 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Richard Shockey
Sent: Monday, August 18, = 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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. =

 

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

cnit@ietf.org

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>
skype= -linkedin-facebook: rshockey101
http://www.sipforum.org

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

 

 

------=_NextPart_000_01D9_01CFBCBB.22BA1380-- From nobody Thu Aug 21 06:13:49 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697711A02AC; Thu, 21 Aug 2014 06:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFTf_VgcNmdT; Thu, 21 Aug 2014 06:13:38 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3EC1A0270; Thu, 21 Aug 2014 06:13:38 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 21 Aug 2014 06:12:53 -0700 From: Michael Hammer To: "richard@shockey.us" , "hala.mowafy@ericsson.com" , "Henning.Schulzrinne@fcc.gov" , "dispatch@ietf.org" , "cnit@ietf.org" Thread-Topic: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPvK0Wx9hBBz9nbUeH4A7JSWEZc5vaBUJAgACwCgCAAFO78A== Date: Thu, 21 Aug 2014 13:12:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBFBEC98@sc9-ex2k10mb1.corp.yaanatech.com> References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> In-Reply-To: <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.158] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001C_01CFBD20.15DCD1B0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/NtU5DDDCWIM78Kf5aXdWS4hNF0w Cc: "stir@ietf.org" Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 13:13:45 -0000 ------=_NextPart_000_001C_01CFBD20.15DCD1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001D_01CFBD20.15DD9500" ------=_NextPart_001_001D_01CFBD20.15DD9500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com From: Richard Shockey [mailto:richard@shockey.us] Sent: Wednesday, August 20, 2014 9:10 PM To: Michael Hammer; hala.mowafy@ericsson.com; Henning.Schulzrinne@fcc.gov; dispatch@ietf.org; cnit@ietf.org Cc: stir@ietf.org Subject: RE: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 Richard, I doubt you can avoid policy and business models. [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. 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. [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. If there were no business need, then no one would need this work. [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 michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Wednesday, August 20, 2014 3:10 PM To: 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 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:cnit-bounces@ietf.org] On Behalf Of Hala Mowafy Sent: Tuesday, August 19, 2014 12:51 AM To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org 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. 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 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 cnit@ietf.org 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> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_001_001D_01CFBD20.15DD9500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 = USA

www.yaanatech.com

 

From:= = Richard Shockey [mailto:richard@shockey.us]
Sent: Wednesday, = August 20, 2014 9:10 PM
To: Michael Hammer; = hala.mowafy@ericsson.com; Henning.Schulzrinne@fcc.gov; = dispatch@ietf.org; cnit@ietf.org
Cc: = stir@ietf.org
Subject: RE: [dispatch] [cnit] [stir] Restarting = the CNAM CNIT proposition at IETF 91

 

 

Richard,

 

I doubt you can avoid = policy and business models.

 

[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/rf= c7095

 

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

 

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.

 

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

 

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

 

[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

michael.hammer@yaanatech.com

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 = USA

www.yaanatech.com

 

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

 

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:cnit-bounces@ietf.org] = On Behalf Of Hala Mowafy
Sent: Tuesday, August 19, 2014 = 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; = 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Henning Schulzrinne
Sent: Monday, August = 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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:stir-bounces@ietf.org] = On Behalf Of Richard Shockey
Sent: Monday, August 18, = 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
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. =

 

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

cnit@ietf.org

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>
skype= -linkedin-facebook: rshockey101
http://www.sipforum.org

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

 

 

------=_NextPart_001_001D_01CFBD20.15DD9500-- ------=_NextPart_000_001C_01CFBD20.15DCD1B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE+zCCBPcCAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAvEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwODIxMTMxMjUyWjAjBgkqhkiG 9w0BCQQxFgQUg9bdwaEr8Z4eK1l2Kwve55X2sQ4wgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZI AWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTEL MAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1h bnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJt ZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcN AQkQAgsxgeGggd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZ UHovRnYwDQYJKoZIhvcNAQEBBQAEggEAkyqzXhlIm5WJ3kPRWvI0fegVKlUrvnTGHzWb+ermicYS rjWhbAZwC1khrrnNulAIMdUrIWDTkK9qhcJMLDOgPpWcGckWrbMqESnDvP43qSQgjsqzDYxohzET H0yVOuJCMsa/lfMeGOKbkAqLTss32eO9AA3i9b4cnoKWtPAyUkX/qtmr2UdIgqCJTAZac6G53ghM vQTHejoqSLIcrQ13Ki9moAJ0QrA1o+UXu2QRcRFsju6levfCYxbZUJd8E7PqDEUpFj83k6SHmWP2 BNY985Zsqgl+ajGM3Mkq5BmSNPfkNgm15k2tPBirwGIazEISRgDplhuNHdPUh7TZFmxLeAAAAAAA AA== ------=_NextPart_000_001C_01CFBD20.15DCD1B0-- From nobody Thu Aug 21 06:33:33 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37761A02E2; Thu, 21 Aug 2014 06:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXWnR_bIMykW; Thu, 21 Aug 2014 06:33:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98E91A02A6; Thu, 21 Aug 2014 06:33:24 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-53-53f59e437461 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9D.4C.25146.34E95F35; Thu, 21 Aug 2014 09:22:43 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 09:33:19 -0400 From: Hala Mowafy To: Henning Schulzrinne , "cnit@ietf.org" Thread-Topic: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPuxq8aLQghJL4fES3fTwwrTuV7pvXVGhwgALGZgCAAPPDIA== Date: Thu, 21 Aug 2014 13:33:17 +0000 Message-ID: <728F35AE98AEDB4A96FF3A32A85A60BB394DD5DD@eusaamb105.ericsson.se> References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_728F35AE98AEDB4A96FF3A32A85A60BB394DD5DDeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHW9d53tdgg+dvTS2uzt7HaPHzyG5W i+VrtzE5MHvcvv2GzWPJkp9MAUxRXDYpqTmZZalF+nYJXBm9/8+wFHzeyVTRu/40cwPjsT6m LkZODgkBE4nfW95D2WISF+6tZ+ti5OIQEjjKKHFpbw87hLOcUaKlfRkjSBWbgI7EnL8fmUFs EYEIiTcPm4G6OTiYBZQl/u22BwkLCzhLfL6xmwWixEVi3qe5UOVOEi9P3AdbxiKgKvHj9G0w m1fAV2LLoQuMELueMUp87jsNluAUsJe4d7gJrJkR6Lrvp9aAxZkFxCVuPZkPdbWAxJI955kh bFGJl4//sULYShIff89nh6jPl5j/ZjULxDJBiZMzn7BMYBSdhWTULCRls5CUQcR1JBbs/sQG YWtLLFv4mhnGPnPgMROy+AJG9lWMHKXFqWW56UaGmxiBUXZMgs1xB+OCT5aHGAU4GJV4eBcU fgkWYk0sK67MPcQozcGiJM6rWT0vWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjshXxPl6/ 7vXwnj7JssYjQaKiwfDDTlfVgt3CgR7rfk1N2vQwla0w98KeNfltZZ06C67O0KhiebtN8r3I lryzP26zGEknrwn18Lx8VHyRXJU587+07LSmsJkxdWfjIkN+zWP45jGDT+HDvjkZQbEhiWwd btdyu2c6/UvbeHNh68O7/092NjkpsRRnJBpqMRcVJwIAtap5u5MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/XM3xfCS58OGXiSVKENZbwfQa5r0 Cc: "stir@ietf.org" Subject: Re: [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 13:33:31 -0000 --_000_728F35AE98AEDB4A96FF3A32A85A60BB394DD5DDeusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Henning, We agree on the end result: reliable ID delivery. My point is that the dis= cussion keeps crossing the problems of one set of "name related" services w= ith others. For LIDBs and CNAM, the service providers perform a certain level of valida= tion when you start service with them (checking a personal ID, a business t= ax ID, address, etc.), which aligns in principle with the goals of strength= ening 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 i= n LIDB. I don't know of any LIDB provider that allows the customer a "con= figure-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 deliv= er 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 everythin= g 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 char= acters along with possible enhancements. From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Wednesday, August 20, 2014 2:46 PM To: Hala Mowafy; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91 Hala, I don't think we're disagreeing, but if anything I said is at odds with you= r description, please say so. I was referring to the many services that pro= vide an API-based service that appears to rely on the same databases for ca= ller name delivery. At least for many telecom service providers, they seem to draw on multiple = LIDB providers, including sometimes configure-your-own-message services lik= e 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 produc= tive to get into how a legacy service is defined, maybe "textual callerID" = is the better term. Henning From: Hala Mowafy [mailto:hala.mowafy@ericsson.com] Sent: Tuesday, August 19, 2014 12:51 AM To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91 Before we go any further on discussing CNAM, we need to clarify the termino= logy 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 se= rvice 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, a= s in a Google look up. Name is delivered to them. - Called party has no choice over the source, e.g., which database t= o query for the name. For most CNAM offerings, the service provider choose= s that database. - In the CNAM service model, since the service provider has business= agreements with the database owner, the name would be considered "traceabl= e" - 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 acc= essing your database, you have control and you can take legal action if som= eone 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 s= omething else other than CNAM. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, August 18, 2014 3:29 PM To: 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91 Thanks for re-starting the discussion. Before getting into the header detai= ls, 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 ca= rrier? Third-party database?) (2) By value and/or by reference: In the location context, we have had l= ong discussions about the trade-offs and I suspect we can learn from that d= ebate. By reference gives you easier scaling to large (possibly signed) obj= ects and differentiated access control. By value requires fewer moving part= s. Allowing for both may allow for trade-offs rather than endless arguments= . (3) Extensibility and rendering: Given the diversity of end systems, ran= ging from very small screens that are only suited for ASCII and text-to-spe= ech systems, to desktop displays, we want this to work reasonably well acro= ss the range of devices, and probably also accommodate different consumer n= eeds (including supporting people with hearing or visual disabilities), alo= ng with robots that use the information to make call routing and call handl= ing 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 la= bor-intensive, particularly to protect the reasonable expectations of priva= te individuals. From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Monday, August 18, 2014 12:59 PM To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org Subject: [stir] Restarting the CNAM CNIT proposition at IETF 91 I have reason to believe it may be useful to revisit the CNAM CNIT proposit= ion during DISPATCH at 91 and see if there is consensus on moving forward o= n 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 de= livered to the User Agent in conjunction with the Caller ID number of the c= alling party. It is typically delivered as a terminating service in SS7 vi= a 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 kn= owledge, 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 rich= er 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. Modificatio= n or a repurposing of the Call-Info header for instance might be a simple w= ay to start. Incorporation of logos, pictures whatever including presentat= ion formats for STIR validation data etc. Creation and transmission is fully governed by existing SIP privacy mechani= sms. Display at termination is governed by UA or service provider policy. There is every reason to National Regulators would be delighted with consu= mers having a richer set of information displayed on their handsets in orde= r to make more informed decisions on whether to accept the session. "Is t= his 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 an= d STIR, by itself, is no 'silver bullet'. I think we have all understood th= at. There are some interesting aspects of this. There are clearly privacy consi= derations however I would argue that the privacy of the called party is wha= t we are trying to protect here. In addition we do not want to see the tech= nique itself become a form of SPAM flooding UA's. What I would propose is a Charter of very very narrow scope. MARTINI as th= e model. 1. What SIP header would carry the CNAM Plus object? 2. What would a CNAM Plus object look like? JSON 3. How is STIR validation data delivered to the UA, presuming that STI= R continues to progress. I would rule out of scope any discussion of how the data in the CNAM Plus o= bject is created, stored, or how its origin is determined or managed. We d= o not want to run down the rat hole of who determines that this Bank or thi= s Doctor is actually the one that creates the data object. That IMHO is so= meone 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 the= se issues on an informal basis now in the review of STIR progress etc. Obvi= ously 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 t= o confine the technical discussion there except for the obvious DISPATCH is= sues etc expressions of interest support etc. cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit Thoughts? ****************** American National Standards Institute (ANSI), Telecommunications Network-to= -Customer Installation Interfaces - Analog Voice grade Switched Access Lin= es with Calling Number Delivery, Calling Name Delivery, or Visual Message-W= aiting Indicator Features, ANSI T1.6401.03-1998 American National Standards Institute (ANSI), Telecommunications- Integrate= d Services Digital Network (ISDN) - Calling Line Identification Presentatio= n and Restriction Supplementary Services, ANSI T1.625-1993 American National Standards Institute ANSI), Telecommunications - Calling N= ame Identification Presentation, ANSI T1.641-1995 Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requi= rements", GR-1188-CORE, Issue 2, December 2000 Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-COR= E, 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 skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm --_000_728F35AE98AEDB4A96FF3A32A85A60BB394DD5DDeusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Henning,

We agree on the end result: reliable ID delivery.&nb= sp; 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 pe= rsonal ID, a business tax ID, address, etc.), which aligns in principle wit= h the goals of strengthening the trust in the “originating” side (such as the goals of STIR).  I= t 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 p= rovider 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 s= imply 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.&= nbsp;  

So when I read the email threads, I ask: ShouldnR= 17;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 re= cord?  I trust we will.

 

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

 

 

From: Henning = Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Wednesday, August 20, 2014 2:46 PM
To: Hala Mowafy; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91<= o:p>

 

Hala,

 

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

 

At least for many tele= com service providers, they seem to draw on multiple LIDB providers, includ= ing 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 co= nfusion and since it doesn’t seem particularly productive to get into= how a legacy service is defined, maybe “textual callerID” is t= he better term.

 

Henning

 

From: Hala Mow= afy [mailto:hala.mowafy@ericsso= n.com]
Sent: Tuesday, August 19, 2014 12:51 AM
To: Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org
Cc: stir@ietf.org
Subject: RE: [stir] Restarting the CNAM CNIT proposition at IETF 91<= o:p>

 

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

-     &= nbsp;  CNAM is a term that the industry uses to refer to a= terminating service where the called party receives the name on an incomin= g call.  It is already used in Standards to refer to that terminating = service.

-     &= nbsp;  The called party does NOT proactively seek or disco= ver the name, as in a Google look up.  Name is delivered to them.=

-     &= nbsp;  Called party has no choice over the source, e.g., w= hich database to query for the name.  For most CNAM offerings, the ser= vice provider chooses that database.

-     &= nbsp;  In the CNAM service model, since the service provid= er has business agreements with the database owner, the name would be consi= dered “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 datab= ase, you have control and you can take legal action if someone tries to = 220;drain” your database or cache data from it. 

-     &= nbsp;  The other sources of “name” that are av= ailable online or otherwise, should not be referred to as CNAM.  You m= ay call them “name lookups” or something else other than CNAM.<= o:p>

 

From: stir [mailto:stir-bounces@ietf= .org] On Behalf Of Henning Schulzrinne
Sent: Monday, August 18, 2014 3:29 PM
To: 'Richard Shockey'; 'DISPATCH'; = cnit@ietf.org
Cc: stir@ietf.org
Subject: Re: [stir] Restarting the CNAM CNIT proposition at IETF 91<= o:p>

 

Thanks for re-starting= the discussion. Before getting into the header details, having a clearer u= nderstanding of the requirements would be useful. To start, I’ll posi= t four:

 

(1)&= nbsp;   Traceable o= rigin: It must be clear to the rec= ipient who vouches for the information. (Assertion of the calling party? So= me licensing authority such as a financial regulator or a professional association? Originating carrier? Third-party = database?)

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

(3)&= nbsp;   Extensibili= ty and rendering: Given the divers= ity of end systems, ranging from very small screens that are only suited fo= r 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 (includ= ing supporting people with hearing or visual disabilities), along with robo= ts that use the information to make call routing and call handling decisions.

(4)&= nbsp;   Privacy: The existing CNAM system has the dis= advantage 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 ht= tp://800notes.com/, there may be ways to protect the interests of both = caller and callee that make systematic and large-scale collection of revers= e mappings more labor-intensive, particularly to protect the reasonable expectations of private individuals. =

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: Monday, August 18, 2014 12:59 PM
To: 'DISPATCH'; cnit@ietf.org Cc: stir@ietf.org
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 consen= sus on moving forward on some level of standardization here.

 

The idea is pretty simple.  We all generally kn= ow 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 t= he Caller ID number of the calling party.  It is typically delivered as a terminating service in SS7 via TCAP from LI= DB databases.

 

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

 

It is not a hard stretch to postulate that called pa= rties 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 o= rigination. 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 f= or STIR validation data etc.

 

Creation and transmission is fully governed by exist= ing SIP privacy mechanisms.

 

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

 

There is every reason to  National Regulators w= ould be delighted with consumers having a richer set of information display= ed 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 spoo= fing problem has not gone away and STIR, by itself, is no ‘silver bul= let’. I think we have all understood that.

 

There are some interesting aspects of this. There ar= e 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 n= ot want to see the technique itself become a form of SPAM flooding UA’s.

 

What I would propose is a Charter of very very narro= w 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 deter= mined or managed.  We do not want to run down the rat hole of who dete= rmines 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 revie= w 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 S= tatement and Requirements so I’m looking for collaborators here.

 

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

 

cnit mailing list

cnit@ietf.org

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

 

Thoughts?

 

 

 

 

 

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

 

American National Standards Institute (ANSI), Teleco= mmunications Network-to-Customer Installation Interfaces - Analog Voice gra= de  Switched Access Lines with Calling Number Delivery, Calling Name D= elivery, or Visual Message-Waiting Indicator Features, ANSI  T1.6401.03-1998

 

American National Standards Institute (ANSI), Teleco= mmunications- Integrated Services Digital Network (ISDN) - Calling Line Ide= ntification Presentation and Restriction Supplementary Services, ANSI T1.62= 5-1993

 

American National Standards Institute ANSI), Telecom= munications - 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<= /a>
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mai= lto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http://www.sipforum.org<= /span>

"Money is the answer, what is the question?" t= m

 

 

--_000_728F35AE98AEDB4A96FF3A32A85A60BB394DD5DDeusaamb105erics_-- From nobody Thu Aug 21 07:57:57 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51801A0113 for ; Thu, 21 Aug 2014 07:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je8eUbX72lmv for ; Thu, 21 Aug 2014 07:57:52 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7671A00DD for ; Thu, 21 Aug 2014 07:57:52 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id hQQd1o00427AodY56SxsZF; Thu, 21 Aug 2014 14:57:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta19.westchester.pa.mail.comcast.net with comcast id hSvr1o00z3Ge9ey3fSvsXx; Thu, 21 Aug 2014 14:55:52 +0000 Message-ID: <53F60877.8050107@alum.mit.edu> Date: Thu, 21 Aug 2014 10:55:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: cnit@ietf.org References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> In-Reply-To: <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408633072; bh=h3RNAvesGz2WzVx8lMsrrl/r5eh4ysNMRSHJUv4QgVU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gTGx4VFLHrZKUFtBlVzx+GPmF9MPOg6t9aj27TrYaDColi1tc1fZvDK3jOxvoiWLr 2+KaxCCQd6WtN0XncJa0RDhlbWg2tPNhoN0W0VEKDudwvNxFmCSlNHuwa558AkGAi5 Pxv7pudQihsFCrKmq18P7p2pKGBeMxu+gGinAMX2JQQcy8vyazpeVRyIP267FgFCy0 NRojg6gfuv32bHyHcRjMxaFMLy3O1MlRicbwPFOV29If5BcaD6452Q8PPB48Tdz2T/ NyY9kC0CiaYr0baCh3aQMRTdi4nYiwbmtC37srQbEdejs0z9tZMQioJSoAIFS+xprw VSXA1eRJEcixA== Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/aIpC04Ztse_eIYS3cOPcExlitCE Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:57:55 -0000 On 8/20/14 9:10 PM, Richard Shockey wrote: > Richard, > > I doubt you can avoid policy and business models. > > */[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. /* > > 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. > > */[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. /* > > If there were no business need, then no one would need this work. > > */[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* > > _michael.hammer@yaanatech.com _ > > *Mobile: *+1**408 202 9291 > > 542 Gibraltar Drive > > Milpitas, CA 95035 USA > > www.yaanatech.com > > *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of > *Richard Shockey > *Sent:* Wednesday, August 20, 2014 3:10 PM > *To:* 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org > > *Cc:* stir@ietf.org > *Subject:* Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT > proposition at IETF 91 > > 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:cnit-bounces@ietf.org] *On Behalf Of *Hala Mowafy > *Sent:* Tuesday, August 19, 2014 12:51 AM > *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org > > *Cc:* stir@ietf.org > *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:stir-bounces@ietf.org] *On Behalf Of *Henning > Schulzrinne > *Sent:* Monday, August 18, 2014 3:29 PM > *To:* 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org > *Cc:* stir@ietf.org > *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:stir-bounces@ietf.org] *On Behalf Of *Richard Shockey > *Sent:* Monday, August 18, 2014 12:59 PM > *To:* 'DISPATCH'; cnit@ietf.org > *Cc:* stir@ietf.org > *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. > > 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 > > 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 > > cnit@ietf.org > > 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 > > skype-linkedin-facebook: rshockey101 > http://www.sipforum.org > > "Money is the answer, what is the question?" tm > > > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > From nobody Thu Aug 21 08:13:55 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550721A03CA for ; Thu, 21 Aug 2014 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkuWC-pawyYC for ; Thu, 21 Aug 2014 08:13:49 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id DBF0E1A00C6 for ; Thu, 21 Aug 2014 08:13:48 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Paul Kyzivat' , "cnit@ietf.org" Thread-Topic: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPvVBNHipw2TiR40+2lSDiYcBuhpvbJjwQ Date: Thu, 21 Aug 2014 15:13:46 +0000 References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F60877.8050107@alum.mit.edu> In-Reply-To: <53F60877.8050107@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/SfVzz5PSGtfQKxa4HFzeBNOBZ6c Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:13:54 -0000 There are, at least, three different kinds of information that have differe= nt trust relationships: (1) Physical address (for non-VoIP or facilities-based VoIP landlines): Gen= erally, if you trust the originating carrier, they know that information. T= he address is often wrong or misleading for OTT VoIP or franchise-style set= tings, 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, bu= t not if the account is pre-pay. Also, I suspect that they don't necessaril= y track changes in business names (particularly DBAs) as long as the bill g= ets paid. My guess is that even for post-pay, there are a fair number of er= rors - somebody else paying the bill, marriage/divorce, name changes, typos= , ... For family wireless accounts, the account holder name is shown (for c= arriers like TMo that provide this at all - most don't). When I call somebo= dy, 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-regi= stered 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 n= o 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 And= roid (https://support.google.com/nexus/answer/3459196?hl=3Den). 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:cnit-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, August 21, 2014 10:56 AM To: cnit@ietf.org Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition = at IETF 91 On 8/20/14 9:10 PM, Richard Shockey wrote: > Richard, > > I doubt you can avoid policy and business models. > > */[RS> ] Agreed but not in the IETF or 3GPP. My overriding concern in=20 > 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=20 > will try and insist on, keeping the focus of the work only on what=20 > goes "on the wire" . We are not competent to make policy or business=20 > model judgments especially on areas related to telephony vs "the=20 > Internet". /* > > *//* > > */IMHO any reasonable deployment scenario for whatever we call this=20 > would end up being part of some other SDO's work. In North America=20 > that would probably be my friends at ATIS which works closely with the=20 > FCC and the CRTC in Canada or in the UK the NICC which performs a=20 > similar technical advisory function for OFCOM. Would ETSI get=20 > involved for Europe as a whole.. Probably. We are not there and nor=20 > should we go there. Its perfectly reasonable for the IETF as=20 > technical experts to describe 'Policy Considerations' but beyond that=20 > we are out of our league./* > > *//* I'm suspect that some of the policy decisions can be deferred as you sugges= t, 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 i= f 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 ma= ke the trust decision on a case-by-case basis. But this is probably impract= ical. Instead, it is likely that the callee's device will be making the tru= st decision, and using it to make some policy decisions on behalf of the ca= llee: 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 asse= rtion of Y if I trust X's STIR assertion of the calling number. But that do= esn'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=20 > 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=20 > text or something. "Trusted by Vodafone" "Not Validated" Something in=20 > the INVITE to the UA that can be displayed. Which is why this is so=20 > important to VoLTE and the mobile handsets. In VoLTE the INVITE=20 > 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=20 > Public SIP Telephone Network now after all for interconnection. /* > > The minute you pose the architectural question of whether this is true=20 > peer-to-peer (aka a protocol independent of SIP), > > or must be provided by the service provider (aka part of the=20 > carrier-controled SIP path), you have already slid down that slope. > > */[RS> ] You want to do peer to peer go ahead. IMHO you are out of=20 > scope for this work. Stick to what is on the wire. /* > > If there were no business need, then no one would need this work. > > */[RS> ] IMHO this is not a business need, though there is certainly a=20 > business model to support the deployment of this. What are we trying=20 > to do here? You don't need me to explain that the contagion of Caller=20 > ID spoofing is driving consumers crazy and driving National Regulatory=20 > Authorities crazy as well. I would argue that STIR and this effort is=20 > a perfectly reasonable Consumer Protection effort. That is honorable=20 > work we all could be proud of. /* > > *//* > > */Can't we make SIP safer for people to use? I am not a regulator nor=20 > do I play one on TV but this IMHO is exactly the kind of thing we as=20 > technical professionals and the IETF .. (don't get me started on ISOC)=20 > should do. It could be pretty simple stuff and it WILL have a=20 > demonstrable and positive impact on the lives of thousands indeed=20 > millions that are dealing with this every single day. /* > > *________________________________* > > *Michael Hammer* > > *Principal Engineer* > > _michael.hammer@yaanatech.com _ > > *Mobile: *+1**408 202 9291 > > 542 Gibraltar Drive > > Milpitas, CA 95035 USA > > www.yaanatech.com > > *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of=20 > *Richard Shockey > *Sent:* Wednesday, August 20, 2014 3:10 PM > *To:* 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org=20 > > *Cc:* stir@ietf.org > *Subject:* Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT=20 > proposition at IETF 91 > > 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=20 > what CNAM is right now and the existing service is somewhat useless=20 > can be spoofed and is a contributing factor to the overall problem of=20 > fraud and abuse that deeply concerns our National Regulators. > > We can call it what every you want. Alas we don't have Hadrial Kaplan=20 > any more to dream up catchy names. > > What I'd like to avoid, though that may not be possible, is a long=20 > running discussion of the policy questions associated with the service=20 > and the design implications. I was trying to focus attention on to=20 > basic elements. One is the object itself that carries the more=20 > extensive calling party information and second how SIP actually=20 > carries it. As Henning points out this may be more complicated with=20 > multimedia elements necessary to accommodate those with disabilities. > > This may require a more extensive Problem Statement and Requirements=20 > incorporating Policy Considerations but we all know what that means=20 > especially if it involves numbering databases or databases indexed by=20 > 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=20 > it is the called party we are trying to protect here. You have no=20 > right to arbitrarily contact me unless I have some mechanism to=20 > validate who you are. "Are you really my bank?" As a personal side=20 > bar I'm never going to accept a point to point SIP/IMS/RCS video call=20 > from anyone unless I have some better data on who is calling me. > > SIP and realtime communications are not email. We are not invalidating=20 > existing SIP privacy mechanisms only making sure that the called party=20 > has sufficient information to make a reasoned judgment whether to=20 > accept the session or not. The calling party can still refuse to send=20 > Enhanced Calling Party Name Information or suppress the CLI for instance. > > I will certainly admit to a bias that designing a system around the=20 > service providers that issued the phone numbers to the parties is not=20 > a bad place to start. Last but not least .. we have no business=20 > discussing business models. I would argue that the security of PII=20 > related databases is out of scope. > > *From:* cnit [mailto:cnit-bounces@ietf.org] *On Behalf Of *Hala Mowafy > *Sent:* Tuesday, August 19, 2014 12:51 AM > *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH';=20 > cnit@ietf.org > *Cc:* stir@ietf.org > *Subject:* Re: [cnit] [stir] Restarting the CNAM CNIT proposition at=20 > IETF 91 > > Before we go any further on discussing CNAM, we need to clarify the=20 > terminology so we can have a productive discussion and more=20 > importantly to prevent any confusion. > > -CNAM is a term that the industry uses to refer to a terminating=20 > service where the called party receives the name on an incoming call. =20 > It is already used in Standards to refer to that terminating service. > > -The called party does NOT proactively seek or discover the name, as=20 > in a Google look up. Name is delivered to them. > > -Called party has no choice over the source, e.g., which database to=20 > query for the name. For most CNAM offerings, the service provider=20 > chooses that database. > > -In the CNAM service model, since the service provider has business=20 > agreements with the database owner, the name would be considered=20 > "traceable" - again, only by the service provider, and not by the=20 > calling or called parties. If you, the database owner, have an=20 > agreement with the entity accessing your database, you have control=20 > and you can take legal action if someone tries to "drain" your=20 > database or cache data from it. > > -The other sources of "name" that are available online or otherwise,=20 > should not be referred to as CNAM. You may call them "name lookups"=20 > or something else other than CNAM. > > *From:*stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Henning=20 > Schulzrinne > *Sent:* Monday, August 18, 2014 3:29 PM > *To:* 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org=20 > > *Cc:* stir@ietf.org > *Subject:* Re: [stir] Restarting the CNAM CNIT proposition at IETF 91 > > Thanks for re-starting the discussion. Before getting into the header=20 > details, having a clearer understanding of the requirements would be=20 > useful. To start, I'll posit four: > > (1)/Traceable origin/: It must be clear to the recipient who vouches=20 > for the information. (Assertion of the calling party? Some licensing=20 > 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=20 > had long discussions about the trade-offs and I suspect we can learn=20 > from that debate. By reference gives you easier scaling to large=20 > (possibly > signed) objects and differentiated access control. By value requires=20 > fewer moving parts. Allowing for both may allow for trade-offs rather=20 > than endless arguments. > > (3)/Extensibility and rendering/: Given the diversity of end systems,=20 > ranging from very small screens that are only suited for ASCII and=20 > text-to-speech systems, to desktop displays, we want this to work=20 > reasonably well across the range of devices, and probably also=20 > accommodate different consumer needs (including supporting people with=20 > hearing or visual disabilities), along with robots that use the=20 > information to make call routing and call handling decisions. > > (4)/Privacy/: The existing CNAM system has the disadvantage that=20 > anybody can find out the name behind any number, rather than just the cal= lee. > While nobody can prevent the callee from posting information on=20 > http://800notes.com/, there may be ways to protect the interests of=20 > both caller and callee that make systematic and large-scale collection=20 > of reverse mappings more labor-intensive, particularly to protect the=20 > reasonable expectations of private individuals. > > *From:*stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Richard=20 > Shockey > *Sent:* Monday, August 18, 2014 12:59 PM > *To:* 'DISPATCH'; cnit@ietf.org > *Cc:* stir@ietf.org > *Subject:* [stir] Restarting the CNAM CNIT proposition at IETF 91 > > I have reason to believe it may be useful to revisit the CNAM CNIT=20 > proposition during DISPATCH at 91 and see if there is consensus on=20 > moving forward on some level of standardization here. > > The idea is pretty simple. We all generally know what CNAM in the=20 > PSTN is. (see below) Calling Name Delivery information is the verbose=20 > ASCII text delivered to the User Agent in conjunction with the Caller=20 > ID number of the calling party. It is typically delivered as a=20 > terminating service in SS7 via TCAP from LIDB databases. > > CNAM as it is currently defined in SS7 is a terrible service. 15=20 > Character ASCII. No support for International characters etc. It has=20 > 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=20 > richer set of data displayed on their UA's and that can be delivered=20 > by the SIP headers in some relatively simple form at session origination. > Modification or a repurposing of the Call-Info header for instance=20 > might be a simple way to start. Incorporation of logos, pictures=20 > whatever including presentation formats for STIR validation data etc. > > Creation and transmission is fully governed by existing SIP privacy=20 > mechanisms. > > Display at termination is governed by UA or service provider policy. > > There is every reason to National Regulators would be delighted with=20 > consumers having a richer set of information displayed on their=20 > handsets in order to make more informed decisions on whether to accept th= e > 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=20 > understood that. > > There are some interesting aspects of this. There are clearly privacy=20 > considerations however I would argue that the privacy of the called=20 > party is what we are trying to protect here. In addition we do not=20 > 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=20 > as the model. > > 1.What SIP header would carry the CNAM Plus object? > > 2.What would a CNAM Plus object look like? JSON > > 3.How is STIR validation data delivered to the UA, presuming that STIR=20 > continues to progress. > > I would rule out of scope any discussion of how the data in the CNAM=20 > Plus object is created, stored, or how its origin is determined or=20 > managed. We do not want to run down the rat hole of who determines=20 > that this Bank or this Doctor is actually the one that creates the=20 > data object. That IMHO is someone else's problem. > > My suspicion is that the IETF is going to need some very close=20 > coordination with 3GPP here. I have on good authority 3GPP is looking=20 > into some of these issues on an informal basis now in the review of=20 > STIR progress etc. Obviously given the ongoing global launch of VoLTE=20 > services this work should be of strong interest. > > I'm willing to take a first cut at a Problem Statement and=20 > Requirements so I'm looking for collaborators here. > > Second we have a list established for this already CNIT..it seems=20 > logical to confine the technical discussion there except for the=20 > obvious DISPATCH issues etc expressions of interest support etc. > > cnit mailing list > > cnit@ietf.org > > https://www.ietf.org/mailman/listinfo/cnit > > Thoughts? > > ****************** > > American National Standards Institute (ANSI), Telecommunications=20 > Network-to-Customer Installation Interfaces - Analog Voice grade=20 > Switched Access Lines with Calling Number Delivery, Calling Name=20 > Delivery, or Visual Message-Waiting Indicator Features, ANSI > T1.6401.03-1998 > > American National Standards Institute (ANSI), Telecommunications-=20 > Integrated Services Digital Network (ISDN) - Calling Line=20 > Identification Presentation and Restriction Supplementary Services,=20 > ANSI T1.625-1993 > > American National Standards Institute ANSI), Telecommunications -=20 > Calling Name Identification Presentation, ANSI T1.641-1995 > > Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic=20 > Requirements", GR-1188-CORE, Issue 2, December 2000 > > Telcordia Technologies, "CLASS Feature: Calling Number Delivery",=20 > 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=20 > 703.593.2683 > skype-linkedin-facebook: rshockey101 > http://www.sipforum.org > > "Money is the answer, what is the question?" tm > > > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Thu Aug 21 08:33:06 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8E1A03B5 for ; Thu, 21 Aug 2014 08:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9oAJXY0qfbi for ; Thu, 21 Aug 2014 08:33:02 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 9001D1A03D9 for ; Thu, 21 Aug 2014 08:32:11 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id hQ5Y1o0030cZkys51TYBn2; Thu, 21 Aug 2014 15:32:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta10.westchester.pa.mail.comcast.net with comcast id hTWA1o00A3Ge9ey3WTWB85; Thu, 21 Aug 2014 15:30:11 +0000 Message-ID: <53F61082.1010708@alum.mit.edu> Date: Thu, 21 Aug 2014 11:30:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Henning Schulzrinne , "cnit@ietf.org" References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F60877.8050107@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408635131; bh=WBAga+8wBxT5oq3TcXeqzWUTsKNMO0xFhQcX6BLpc3Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Z6wkVsxB+6OIMAcJmrqWAHEQkObqYqHo0ITboyRPOm9Nl/IQZQzS9hIO3mQyU3nc9 gkrrI57KLBTkE9WCI6c7Eq5/qkQ2DnZcmxz/xnIKX7hGDRnujEWlvMsmX8dE3DefJ7 al3AjLQghYFOqLLixgch4kRHSccGnz6mwcrwr7NkY2E9wql0nDvbfJUtC5o2y5JfCE eFmK909u+5ozy14Lt1RlPIeI4pvp1nJo8zhP3moJ1mt0IIFUozPCcY9tQzatgwRdpF IHnC2FFpZSxYTKqZyYisqZCVbH2EM31vvm/fdpUZtdWwDi5TDfz2Ur1Zsbh4fpiip0 5KtegXHy9VCZw== Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/kXFc2uFi-2OUxrMt_5yH_DEfiX4 Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:33:05 -0000 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: > 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:cnit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 21, 2014 10:56 AM > To: cnit@ietf.org > Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 > > On 8/20/14 9:10 PM, Richard Shockey wrote: >> Richard, >> >> I doubt you can avoid policy and business models. >> >> */[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. /* >> >> 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. >> >> */[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. /* >> >> If there were no business need, then no one would need this work. >> >> */[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* >> >> _michael.hammer@yaanatech.com _ >> >> *Mobile: *+1**408 202 9291 >> >> 542 Gibraltar Drive >> >> Milpitas, CA 95035 USA >> >> www.yaanatech.com >> >> *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of >> *Richard Shockey >> *Sent:* Wednesday, August 20, 2014 3:10 PM >> *To:* 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org >> >> *Cc:* stir@ietf.org >> *Subject:* Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT >> proposition at IETF 91 >> >> 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:cnit-bounces@ietf.org] *On Behalf Of *Hala Mowafy >> *Sent:* Tuesday, August 19, 2014 12:51 AM >> *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; >> cnit@ietf.org >> *Cc:* stir@ietf.org >> *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:stir-bounces@ietf.org] *On Behalf Of *Henning >> Schulzrinne >> *Sent:* Monday, August 18, 2014 3:29 PM >> *To:* 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org >> >> *Cc:* stir@ietf.org >> *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:stir-bounces@ietf.org] *On Behalf Of *Richard >> Shockey >> *Sent:* Monday, August 18, 2014 12:59 PM >> *To:* 'DISPATCH'; cnit@ietf.org >> *Cc:* stir@ietf.org >> *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. >> >> 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 >> >> 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 >> >> cnit@ietf.org >> >> 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 >> skype-linkedin-facebook: rshockey101 >> http://www.sipforum.org >> >> "Money is the answer, what is the question?" tm >> >> >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >> > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > > From nobody Thu Aug 21 08:48:02 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D11C1A033D for ; Thu, 21 Aug 2014 08:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrN2xoDQ0jTK for ; Thu, 21 Aug 2014 08:47:55 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 770201A0193 for ; Thu, 21 Aug 2014 08:47:54 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Paul Kyzivat' , "cnit@ietf.org" Thread-Topic: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPvVBNHipw2TiR40+2lSDiYcBuhpvbJjwQgABLxwD//78PcA== Date: Thu, 21 Aug 2014 15:47:53 +0000 References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F60877.8050107@alum.mit.edu> <53F61082.1010708@alum.mit.edu> In-Reply-To: <53F61082.1010708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/AwB6Lm1mDdhBiiDJTMKQsQVrxYw Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:48:00 -0000 My main point was that it seems likely that for different kinds of useful i= nformation, different sources are likely to be authoritative, and any solut= ion, 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 strawma= n, if you start with SIP Call-Info, you can picture one or more HTTP retrie= vals of a signed JSON object or an implicit signing by retrieving from a tr= usted HTTPS source. (For example, maybe there's a charity registry that the= recipient trusts or a reference to Dun&Bradstreet or a Realtor licensing e= ntity.) In that model, STIR cryptographically ties the assertions to the ca= ll request, but the validation of the actual information is done by the cal= l recipient, and separately. You also have to make sure that the caller is = authorized to link to a particular information object; we provided mechanis= m in the ARID proposal, but there are other options, e.g., through the phon= e number. (The recipient will only trust the information if that informatio= n 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-r= eference, but that seems to require additional protocol standards work. I would guess that the "whom do you trust" decision will be somewhat automa= ted and delegated, rather than end users digging through X.509 certificates= . -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Thursday, August 21, 2014 11:30 AM To: Henning Schulzrinne; cnit@ietf.org 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.=20 Certainly there needs to be room for applying policy, but ISTM there must b= e a framework with the policy decision points well identified. Thanks, Paul On 8/21/14 11:13 AM, Henning Schulzrinne wrote: > There are, at least, three different kinds of information that have diffe= rent trust relationships: > > (1) Physical address (for non-VoIP or facilities-based VoIP landlines): G= enerally, if you trust the originating carrier, they know that information.= The address is often wrong or misleading for OTT VoIP or franchise-style s= ettings, where the address would reflect some corporate HQ or billing addre= ss, 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 necessar= ily 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, typ= os, ... 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 some= body, it announces me as my wife's name. > > (3) Property assertion: The most interesting information is often what ki= nd of entity the caller is, e.g., whether the caller is actually a state-re= gistered charity or a real medical provider or a licensed chimney sweep. Th= e 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 th= at the database dip is done by the terminating carrier. As one random examp= le of how things are changing, Google now offer a version of caller ID on A= ndroid (https://support.google.com/nexus/answer/3459196?hl=3Den). > > For what it's worth, Kumiko Ono and I looked at this problem years ago, i= n the ARID proposal. > > Henning > > -----Original Message----- > From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 21, 2014 10:56 AM > To: cnit@ietf.org > Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT=20 > proposition at IETF 91 > > On 8/20/14 9:10 PM, Richard Shockey wrote: >> Richard, >> >> I doubt you can avoid policy and business models. >> >> */[RS> ] Agreed but not in the IETF or 3GPP. My overriding concern in=20 >> 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=20 >> I will try and insist on, keeping the focus of the work only on what=20 >> goes "on the wire" . We are not competent to make policy or business=20 >> model judgments especially on areas related to telephony vs "the=20 >> Internet". /* >> >> *//* >> >> */IMHO any reasonable deployment scenario for whatever we call this=20 >> would end up being part of some other SDO's work. In North America=20 >> that would probably be my friends at ATIS which works closely with=20 >> the FCC and the CRTC in Canada or in the UK the NICC which performs a=20 >> similar technical advisory function for OFCOM. Would ETSI get=20 >> involved for Europe as a whole.. Probably. We are not there and nor=20 >> should we go there. Its perfectly reasonable for the IETF as=20 >> technical experts to describe 'Policy Considerations' but beyond that=20 >> we are out of our league./* >> >> *//* > > I'm suspect that some of the policy decisions can be deferred as you sugg= est, but I also suspect that there are architectural issues that affect tho= se policy issues. > > At the end of the day the callee will receive an assertion: X says the na= me 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 impra= ctical. Instead, it is likely that the callee's device will be making the t= rust 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 mak= e 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 as= sertion 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=20 >> 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=20 >> validation text or something. "Trusted by Vodafone" "Not Validated"=20 >> Something in the INVITE to the UA that can be displayed. Which is why=20 >> this is so important to VoLTE and the mobile handsets. In VoLTE the=20 >> INVITE reaches the handset so yes it really is a issue for Apple and And= roid as well. >> Not to mention how WEBRTC deals with Calling Party Info. It's the=20 >> Public SIP Telephone Network now after all for interconnection. /* >> >> The minute you pose the architectural question of whether this is=20 >> true peer-to-peer (aka a protocol independent of SIP), >> >> or must be provided by the service provider (aka part of the=20 >> carrier-controled SIP path), you have already slid down that slope. >> >> */[RS> ] You want to do peer to peer go ahead. IMHO you are out of=20 >> scope for this work. Stick to what is on the wire. /* >> >> If there were no business need, then no one would need this work. >> >> */[RS> ] IMHO this is not a business need, though there is certainly=20 >> a business model to support the deployment of this. What are we=20 >> trying to do here? You don't need me to explain that the contagion=20 >> of Caller ID spoofing is driving consumers crazy and driving National=20 >> Regulatory Authorities crazy as well. I would argue that STIR and=20 >> this effort is a perfectly reasonable Consumer Protection effort. =20 >> 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=20 >> nor do I play one on TV but this IMHO is exactly the kind of thing we=20 >> as technical professionals and the IETF .. (don't get me started on=20 >> ISOC) should do. It could be pretty simple stuff and it WILL have a=20 >> demonstrable and positive impact on the lives of thousands indeed=20 >> millions that are dealing with this every single day. /* >> >> *________________________________* >> >> *Michael Hammer* >> >> *Principal Engineer* >> >> _michael.hammer@yaanatech.com _ >> >> *Mobile: *+1**408 202 9291 >> >> 542 Gibraltar Drive >> >> Milpitas, CA 95035 USA >> >> www.yaanatech.com >> >> *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of=20 >> *Richard Shockey >> *Sent:* Wednesday, August 20, 2014 3:10 PM >> *To:* 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org=20 >> >> *Cc:* stir@ietf.org >> *Subject:* Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT=20 >> proposition at IETF 91 >> >> 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=20 >> what CNAM is right now and the existing service is somewhat useless=20 >> can be spoofed and is a contributing factor to the overall problem of=20 >> fraud and abuse that deeply concerns our National Regulators. >> >> We can call it what every you want. Alas we don't have Hadrial=20 >> Kaplan any more to dream up catchy names. >> >> What I'd like to avoid, though that may not be possible, is a long=20 >> running discussion of the policy questions associated with the=20 >> service and the design implications. I was trying to focus attention=20 >> on to basic elements. One is the object itself that carries the more=20 >> extensive calling party information and second how SIP actually=20 >> carries it. As Henning points out this may be more complicated with=20 >> multimedia elements necessary to accommodate those with disabilities. >> >> This may require a more extensive Problem Statement and Requirements=20 >> incorporating Policy Considerations but we all know what that means=20 >> especially if it involves numbering databases or databases indexed by=20 >> 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 o= ut. >> >> Privacy is a complicated problem but I start from the inference that=20 >> it is the called party we are trying to protect here. You have no=20 >> right to arbitrarily contact me unless I have some mechanism to=20 >> validate who you are. "Are you really my bank?" As a personal side=20 >> bar I'm never going to accept a point to point SIP/IMS/RCS video call=20 >> from anyone unless I have some better data on who is calling me. >> >> SIP and realtime communications are not email. We are not=20 >> invalidating existing SIP privacy mechanisms only making sure that=20 >> the called party has sufficient information to make a reasoned=20 >> judgment whether to accept the session or not. The calling party can=20 >> 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=20 >> service providers that issued the phone numbers to the parties is not=20 >> a bad place to start. Last but not least .. we have no business=20 >> discussing business models. I would argue that the security of PII=20 >> related databases is out of scope. >> >> *From:* cnit [mailto:cnit-bounces@ietf.org] *On Behalf Of *Hala=20 >> Mowafy >> *Sent:* Tuesday, August 19, 2014 12:51 AM >> *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH';=20 >> cnit@ietf.org >> *Cc:* stir@ietf.org >> *Subject:* Re: [cnit] [stir] Restarting the CNAM CNIT proposition at=20 >> IETF 91 >> >> Before we go any further on discussing CNAM, we need to clarify the=20 >> terminology so we can have a productive discussion and more=20 >> importantly to prevent any confusion. >> >> -CNAM is a term that the industry uses to refer to a terminating=20 >> 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=20 >> in a Google look up. Name is delivered to them. >> >> -Called party has no choice over the source, e.g., which database to=20 >> query for the name. For most CNAM offerings, the service provider=20 >> chooses that database. >> >> -In the CNAM service model, since the service provider has business=20 >> agreements with the database owner, the name would be considered=20 >> "traceable" - again, only by the service provider, and not by the=20 >> calling or called parties. If you, the database owner, have an=20 >> agreement with the entity accessing your database, you have control=20 >> and you can take legal action if someone tries to "drain" your=20 >> database or cache data from it. >> >> -The other sources of "name" that are available online or otherwise,=20 >> should not be referred to as CNAM. You may call them "name lookups" >> or something else other than CNAM. >> >> *From:*stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Henning=20 >> Schulzrinne >> *Sent:* Monday, August 18, 2014 3:29 PM >> *To:* 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org=20 >> >> *Cc:* stir@ietf.org >> *Subject:* Re: [stir] Restarting the CNAM CNIT proposition at IETF 91 >> >> Thanks for re-starting the discussion. Before getting into the header=20 >> details, having a clearer understanding of the requirements would be=20 >> useful. To start, I'll posit four: >> >> (1)/Traceable origin/: It must be clear to the recipient who vouches=20 >> for the information. (Assertion of the calling party? Some licensing=20 >> 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=20 >> had long discussions about the trade-offs and I suspect we can learn=20 >> from that debate. By reference gives you easier scaling to large=20 >> (possibly >> signed) objects and differentiated access control. By value requires=20 >> fewer moving parts. Allowing for both may allow for trade-offs rather=20 >> than endless arguments. >> >> (3)/Extensibility and rendering/: Given the diversity of end systems,=20 >> ranging from very small screens that are only suited for ASCII and=20 >> text-to-speech systems, to desktop displays, we want this to work=20 >> reasonably well across the range of devices, and probably also=20 >> accommodate different consumer needs (including supporting people=20 >> with hearing or visual disabilities), along with robots that use the=20 >> information to make call routing and call handling decisions. >> >> (4)/Privacy/: The existing CNAM system has the disadvantage that=20 >> anybody can find out the name behind any number, rather than just the ca= llee. >> While nobody can prevent the callee from posting information on=20 >> http://800notes.com/, there may be ways to protect the interests of=20 >> both caller and callee that make systematic and large-scale=20 >> collection of reverse mappings more labor-intensive, particularly to=20 >> protect the reasonable expectations of private individuals. >> >> *From:*stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Richard=20 >> Shockey >> *Sent:* Monday, August 18, 2014 12:59 PM >> *To:* 'DISPATCH'; cnit@ietf.org >> *Cc:* stir@ietf.org >> *Subject:* [stir] Restarting the CNAM CNIT proposition at IETF 91 >> >> I have reason to believe it may be useful to revisit the CNAM CNIT=20 >> proposition during DISPATCH at 91 and see if there is consensus on=20 >> moving forward on some level of standardization here. >> >> The idea is pretty simple. We all generally know what CNAM in the=20 >> PSTN is. (see below) Calling Name Delivery information is the verbose=20 >> ASCII text delivered to the User Agent in conjunction with the Caller=20 >> ID number of the calling party. It is typically delivered as a=20 >> terminating service in SS7 via TCAP from LIDB databases. >> >> CNAM as it is currently defined in SS7 is a terrible service. 15=20 >> Character ASCII. No support for International characters etc. It=20 >> 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=20 >> a richer set of data displayed on their UA's and that can be=20 >> delivered by the SIP headers in some relatively simple form at session o= rigination. >> Modification or a repurposing of the Call-Info header for instance=20 >> might be a simple way to start. Incorporation of logos, pictures=20 >> whatever including presentation formats for STIR validation data etc. >> >> Creation and transmission is fully governed by existing SIP privacy=20 >> mechanisms. >> >> Display at termination is governed by UA or service provider policy. >> >> There is every reason to National Regulators would be delighted with=20 >> consumers having a richer set of information displayed on their=20 >> handsets in order to make more informed decisions on whether to accept t= he >> 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=20 >> understood that. >> >> There are some interesting aspects of this. There are clearly privacy=20 >> considerations however I would argue that the privacy of the called=20 >> party is what we are trying to protect here. In addition we do not=20 >> 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=20 >> as the model. >> >> 1.What SIP header would carry the CNAM Plus object? >> >> 2.What would a CNAM Plus object look like? JSON >> >> 3.How is STIR validation data delivered to the UA, presuming that=20 >> STIR continues to progress. >> >> I would rule out of scope any discussion of how the data in the CNAM=20 >> Plus object is created, stored, or how its origin is determined or=20 >> managed. We do not want to run down the rat hole of who determines=20 >> that this Bank or this Doctor is actually the one that creates the=20 >> data object. That IMHO is someone else's problem. >> >> My suspicion is that the IETF is going to need some very close=20 >> coordination with 3GPP here. I have on good authority 3GPP is=20 >> looking into some of these issues on an informal basis now in the=20 >> review of STIR progress etc. Obviously given the ongoing global=20 >> launch of VoLTE services this work should be of strong interest. >> >> I'm willing to take a first cut at a Problem Statement and=20 >> Requirements so I'm looking for collaborators here. >> >> Second we have a list established for this already CNIT..it seems=20 >> logical to confine the technical discussion there except for the=20 >> obvious DISPATCH issues etc expressions of interest support etc. >> >> cnit mailing list >> >> cnit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cnit >> >> Thoughts? >> >> ****************** >> >> American National Standards Institute (ANSI), Telecommunications=20 >> Network-to-Customer Installation Interfaces - Analog Voice grade=20 >> Switched Access Lines with Calling Number Delivery, Calling Name=20 >> Delivery, or Visual Message-Waiting Indicator Features, ANSI >> T1.6401.03-1998 >> >> American National Standards Institute (ANSI), Telecommunications-=20 >> Integrated Services Digital Network (ISDN) - Calling Line=20 >> Identification Presentation and Restriction Supplementary Services,=20 >> ANSI T1.625-1993 >> >> American National Standards Institute ANSI), Telecommunications -=20 >> Calling Name Identification Presentation, ANSI T1.641-1995 >> >> Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic=20 >> Requirements", GR-1188-CORE, Issue 2, December 2000 >> >> Telcordia Technologies, "CLASS Feature: Calling Number Delivery",=20 >> 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 >> skype-linkedin-facebook: rshockey101 >> http://www.sipforum.org >> >> "Money is the answer, what is the question?" tm >> >> >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >> > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > > From nobody Thu Aug 21 10:58:00 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A06E1A0722 for ; Thu, 21 Aug 2014 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6gUQa2iR1IE for ; Thu, 21 Aug 2014 10:57:53 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id E550F1A0707 for ; Thu, 21 Aug 2014 10:57:52 -0700 (PDT) Received: (qmail 7533 invoked by uid 0); 21 Aug 2014 17:57:52 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 21 Aug 2014 17:57:52 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id hbdn1o00M1MNPNq01bdqLu; Thu, 21 Aug 2014 17:37:51 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=BMsbjztIcqoA:10 a=aXjNIWwuwdoA:10 a=zsg0ix40YlEA:10 a=kj9zAlcOel0A:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=scBmumm3AAAA:8 a=r3bLr36jAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=EdTE4R_5c06tcdYHKHUA:9 a=ftCsd_25P5XlWm63:21 a=W6ZtX8MWc8pasz7Q:21 a=CjuIK1q_8ugA:10 a=_Fszbdv8evYA:10 a=ivbTfD_dPm4A:10 a=gXXdcPqdfK4A:10 a=lZB815dzVvQA:10 a=E7MB4TUEIZIA:10 a=vRAbILRZcFsA:10 a=emTtFift818A:10 a=NWVoK91CQyQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=YCWEAcNpBSmrqodfAk2oUDONxgODhnlKDLeIq/z1+c0=; b=mOTMZjiAjMdBv38hsyAH3mkIAIQIW4SAZe5rTGnnMWFI6XiLGPOL9fQo4Z1IFiM/z6e+IcBnzZ6vA6b/DCY3ASrN9Tj4MGTymbmk6DdHTl9CcvRs2fS3m6mgFyJFAj41; Received: from [72.66.64.164] (port=53218 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKWJ2-0004Tg-5s; Thu, 21 Aug 2014 11:37:48 -0600 From: "Richard Shockey" To: "'Henning Schulzrinne'" , "'Paul Kyzivat'" , References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F60877.8050107@alum.mit.edu> <53F61082.1010708@alum.mit.edu> In-Reply-To: Date: Thu, 21 Aug 2014 13:37:42 -0400 Message-ID: <010a01cfbd66$9f017360$dd045a20$@shockey.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK+CaJT9Gl0BGzxyNJg2fKi/ufaXQKF81MWAdPt8M8Cfny6QgFoB149AWqOE4sBWnA4WgJdE9UYAjJVNJ4CC+kQc5lxrRxg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/ig0SDlfzizj8ZNstAWQ20-8oKNs Cc: dispatch@ietf.org Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:57:56 -0000 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:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Thursday, August 21, 2014 11:48 AM To: 'Paul Kyzivat'; cnit@ietf.org 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:pkyzivat@alum.mit.edu] Sent: Thursday, August 21, 2014 11:30 AM To: Henning Schulzrinne; cnit@ietf.org 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: > 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:cnit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, August 21, 2014 10:56 AM > To: cnit@ietf.org > Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT > proposition at IETF 91 > > On 8/20/14 9:10 PM, Richard Shockey wrote: >> Richard, >> >> I doubt you can avoid policy and business models. >> >> */[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. /* >> >> 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. >> >> */[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. /* >> >> If there were no business need, then no one would need this work. >> >> */[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* >> >> _michael.hammer@yaanatech.com _ >> >> *Mobile: *+1**408 202 9291 >> >> 542 Gibraltar Drive >> >> Milpitas, CA 95035 USA >> >> www.yaanatech.com >> >> *From:*dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of >> *Richard Shockey >> *Sent:* Wednesday, August 20, 2014 3:10 PM >> *To:* 'Hala Mowafy'; 'Henning Schulzrinne'; 'DISPATCH'; cnit@ietf.org >> >> *Cc:* stir@ietf.org >> *Subject:* Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT >> proposition at IETF 91 >> >> 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:cnit-bounces@ietf.org] *On Behalf Of *Hala >> Mowafy >> *Sent:* Tuesday, August 19, 2014 12:51 AM >> *To:* Henning Schulzrinne; 'Richard Shockey'; 'DISPATCH'; >> cnit@ietf.org >> *Cc:* stir@ietf.org >> *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:stir-bounces@ietf.org] *On Behalf Of *Henning >> Schulzrinne >> *Sent:* Monday, August 18, 2014 3:29 PM >> *To:* 'Richard Shockey'; 'DISPATCH'; cnit@ietf.org >> >> *Cc:* stir@ietf.org >> *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:stir-bounces@ietf.org] *On Behalf Of *Richard >> Shockey >> *Sent:* Monday, August 18, 2014 12:59 PM >> *To:* 'DISPATCH'; cnit@ietf.org >> *Cc:* stir@ietf.org >> *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. >> >> 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 >> >> 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 >> >> cnit@ietf.org >> >> 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 >> skype-linkedin-facebook: rshockey101 >> http://www.sipforum.org >> >> "Money is the answer, what is the question?" tm >> >> >> >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >> > > _______________________________________________ > cnit mailing list > cnit@ietf.org > https://www.ietf.org/mailman/listinfo/cnit > > _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit From nobody Thu Aug 21 11:12:00 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916AC1A6FD3; Thu, 21 Aug 2014 11:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOM2Esa6HhLz; Thu, 21 Aug 2014 11:11:56 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id AE2ED1A0703; Thu, 21 Aug 2014 11:11:55 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: 'Richard Shockey' , 'Paul Kyzivat' , "cnit@ietf.org" Thread-Topic: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 Thread-Index: AQHPvVBNHipw2TiR40+2lSDiYcBuhpvbJjwQgABLxwD//78PcIAAZJMA///F/DA= Date: Thu, 21 Aug 2014 18:11:53 +0000 References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F60877.8050107@alum.mit.edu> <53F61082.1010708@alum.mit.edu> <010a01cfbd66$9f017360$dd045a20$@shockey.us> In-Reply-To: <010a01cfbd66$9f017360$dd045a20$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/s2eRbdj3ST7mdwZBuOIz-p_FX3Y Cc: "dispatch@ietf.org" Subject: Re: [cnit] [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:11:57 -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:richard@shockey.us]=20 Sent: Thursday, August 21, 2014 1:38 PM To: Henning Schulzrinne; 'Paul Kyzivat'; cnit@ietf.org Cc: dispatch@ietf.org 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 to= ols 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 i= t 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 car= efully crafted to limit scope. That is the problem DISPATCH and the AD's wi= ll have to confront at some point in time. From nobody Tue Aug 26 08:17:05 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C601A048D; Sat, 23 Aug 2014 13:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INjHvIQsEeFr; Sat, 23 Aug 2014 13:59:04 -0700 (PDT) Received: from extmail1.yaanatech.com (extmail1.yaanatech.com [63.128.177.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2253C1A0689; Sat, 23 Aug 2014 13:59:04 -0700 (PDT) Received: from [192.168.1.51] (pool-71-171-106-160.clppva.fios.verizon.net [71.171.106.160]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 8BEC558097; Sat, 23 Aug 2014 21:00:56 +0000 (UTC) Message-ID: <53F90096.6040503@yaanatech.com> Date: Sat, 23 Aug 2014 16:59:02 -0400 From: Tony Rutkowski Organization: Yaana Technologies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Richard Shockey , 'Michael Hammer' , hala.mowafy@ericsson.com, Henning.Schulzrinne@fcc.gov, dispatch@ietf.org, cnit@ietf.org References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> In-Reply-To: <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> Content-Type: multipart/alternative; boundary="------------060306020109000501010905" Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/rYxRAFLSX4_63sLQaFLmbqDACec X-Mailman-Approved-At: Tue, 26 Aug 2014 08:17:00 -0700 Cc: stir@ietf.org Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tony@yaanatech.com List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 20:59:05 -0000 This is a multi-part message in MIME format. --------------060306020109000501010905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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: > > */IMHO any reasonable deployment scenario for whatever we call this=20 > would end up being part of some other SDO=92s work. In North America=20 > 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=20 > similar technical advisory function for OFCOM. Would ETSI get=20 > involved for Europe as a whole.. Probably. We are not there and nor=20 > should we go there. Its perfectly reasonable for the IETF as=20 > technical experts to describe =91Policy Considerations=92 but beyond th= at=20 > we are out of our league./* > > *//* > --=20 ________________________________ ** *Tony Rutkowski* EVP, Industry Standards & Regulatory Affairs tony@yaanatech.com ** *Yaana Technologies LLC * 542 Gibraltar Drive Milpitas CA 95035 USA --------------060306020109000501010905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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:

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.


--

________________________________

Tony Rutkowski

EVP, Industry Standards & Regulatory Affairs

tony@yaanatech.com

Yaana Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 USA

--------------060306020109000501010905-- From nobody Wed Aug 27 09:36:15 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9FD1A0B78 for ; Wed, 27 Aug 2014 09:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-DeQ8NE6OCu for ; Wed, 27 Aug 2014 09:36:08 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 3FE8C1A0B81 for ; Wed, 27 Aug 2014 09:36:07 -0700 (PDT) Received: (qmail 26135 invoked by uid 0); 27 Aug 2014 16:36:00 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 27 Aug 2014 16:36:00 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id jsbu1o00M1MNPNq01sbxX4; Wed, 27 Aug 2014 10:35:58 -0600 X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=efyme5masWUA:10 a=a5MIJzeL9VMA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=Zr7miEi8wWIA:10 a=cKsnjEOsciEA:10 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=scBmumm3AAAA:8 a=8_1BJTPJLu9v2JhqflQA:9 a=0zqLIF_QgJWg_3XV:21 a=iaIZm3XcdZdlToET:21 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=f7GxY0FH8QIA:10 a=E7MB4TUEIZIA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=yxZMe7EtEDvsoWJpOlYA:9 a=9I1Mz3neW073_uUy:21 a=wI8haHDUHXjP4-9r:21 a=fu8MrLNnVqI4C13c:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Fm/N85bcgL1HnzcsI9TiLgYebmRQLrzTIK7quS7KYWs=; b=mAbNR2HU6+vE/fzjfCAK7vPBz7hNU8StaT0+nxvSoeDQa9j6U3daj+M/OmwRcR6mGhIN8BPM3jA05J1oQoEoeXsYEp8cOBM569NuaOHTXGQEHAGxgLijvNvQ8AgdTcYx; Received: from [72.66.64.164] (port=51889 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XMgCQ-0006Un-Q9; Wed, 27 Aug 2014 10:35:55 -0600 From: "Richard Shockey" To: , "'Michael Hammer'" , , , , References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F90096.6040503@yaanatech.com> In-Reply-To: <53F90096.6040503@yaanatech.com> Date: Wed, 27 Aug 2014 12:35:47 -0400 Message-ID: <00a501cfc214$f6d4f640$e47ee2c0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01CFC1F3.6FC79C00" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK+CaJT9Gl0BGzxyNJg2fKi/ufaXQKF81MWAdPt8M8Cfny6QgFoB149AWqOE4sCeolj7Zmm5vaA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/7_wQjoHlPmH1dgw3BBzrI8umhSc Cc: stir@ietf.org Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:36:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A6_01CFC1F3.6FC79C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:cnit-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Saturday, August 23, 2014 4:59 PM To: Richard Shockey; 'Michael Hammer'; hala.mowafy@ericsson.com; Henning.Schulzrinne@fcc.gov; dispatch@ietf.org; cnit@ietf.org Cc: stir@ietf.org Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT proposition at IETF 91 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: 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. -- ________________________________ Tony Rutkowski EVP, Industry Standards & Regulatory Affairs tony@yaanatech.com Yaana Technologies LLC 542 Gibraltar Drive Milpitas CA 95035 USA ------=_NextPart_000_00A6_01CFC1F3.6FC79C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Tony = Rutkowski
Sent: Saturday, August 23, 2014 4:59 = PM
To: Richard Shockey; 'Michael Hammer'; = hala.mowafy@ericsson.com; Henning.Schulzrinne@fcc.gov; = dispatch@ietf.org; cnit@ietf.org
Cc: = stir@ietf.org
Subject: Re: [cnit] [stir] [dispatch] Restarting = the CNAM CNIT proposition at IETF 91

 

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:

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.

 

-- =

________________________________ =

Tony = Rutkowski

EVP, Industry Standards & = Regulatory Affairs

tony@yaanatech.com =

Yaana = Technologies LLC

542 Gibraltar Drive

Milpitas CA 95035 = USA

------=_NextPart_000_00A6_01CFC1F3.6FC79C00-- From nobody Thu Aug 28 14:14:40 2014 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61E61A01FA for ; Thu, 28 Aug 2014 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.88 X-Spam-Level: X-Spam-Status: No, score=0.88 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq2XuTmndlVE for ; Thu, 28 Aug 2014 14:14:34 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874E81A01EF for ; Thu, 28 Aug 2014 14:14:34 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so1302585qaq.24 for ; Thu, 28 Aug 2014 14:14:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Ek4rZYSSGCI3ek+KixsVMwTH5V7uVbtwY0ohwjU99Es=; b=CuABCqpCWnx9a08FsLl9HKsR4lmlc7YNgYqUbkaMoY5YbCHP5vMhFrPWqku0E4+fsE ViTV2+nwY999ckHMthdQpZQ7iCFW+sAibHIrRu7sXUuV2STeKedofigv3WMKKR2g6AzY BKwlnBc8FAhcwS2fcuTGLxeLI98GVrmU3ZUcpOrfSchN5Xt715tgP27AA3aBx5yqYDyr JI0iIgkdOG1o6XuPh7DmXl3NNQq3XhHps+bM0kq2uWSbuwf84TixmcExvDWg//jOPTE8 lJrvYreCKQzRTHeoF2Dpmfm1CBe7cvnvjlD7WnsBmojZFGAmO2LPhrd2y0SKnox8KK1c dLtA== X-Gm-Message-State: ALoCoQlsJ6FCbliq7MlPacsrFPIC2d4xnArW0YUnvnzkPwleUW8VwuEtnQkO1uwzvUj78A6C7z2p X-Received: by 10.140.34.164 with SMTP id l33mr7849585qgl.72.1409260473760; Thu, 28 Aug 2014 14:14:33 -0700 (PDT) Received: from [10.33.193.50] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id e64sm7327440qgd.37.2014.08.28.14.14.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Aug 2014 14:14:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5F27FDE0-26FC-49D3-B5EF-6CF1C7F8D708" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: <00a501cfc214$f6d4f640$e47ee2c0$@shockey.us> Date: Thu, 28 Aug 2014 17:14:31 -0400 Message-Id: <8E485E30-83C3-47D6-BE55-E162EAE7DFEE@brianrosen.net> References: <00db01cfbb05$be76c8c0$3b645a40$@shockey.us> <728F35AE98AEDB4A96FF3A32A85A60BB394D808F@eusaamb105.ericsson.se> <010601cfbcaa$55be97d0$013bc770$@shockey.us> <00C069FD01E0324C9FFCADF539701DB3BBFBEA02@sc9-ex2k10mb1.corp.yaanatech.com> <01d801cfbcdc$a9c59900$fd50cb00$@shockey.us> <53F90096.6040503@yaanatech.com> <00a501cfc214$f6d4f640$e47ee2c0$@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/cnit/U75USvog3jvo2stzjfDTke3dsqI Cc: hala.mowafy@ericsson.com, dispatch@ietf.org, tony@yaanatech.com, cnit@ietf.org, stir@ietf.org, Michael Hammer , Henning.Schulzrinne@fcc.gov Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:14:37 -0000 --Apple-Mail=_5F27FDE0-26FC-49D3-B5EF-6CF1C7F8D708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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. =20 We certainly must allow internationalized names, that=92s 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, =85 I=92m 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 = 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. > =20 > Let the NRA=92s deal with policy. That is my point. > =20 > 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. > =20 > From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Tony Rutkowski > Sent: Saturday, August 23, 2014 4:59 PM > To: Richard Shockey; 'Michael Hammer'; hala.mowafy@ericsson.com; = Henning.Schulzrinne@fcc.gov; dispatch@ietf.org; cnit@ietf.org > Cc: stir@ietf.org > Subject: Re: [cnit] [stir] [dispatch] Restarting the CNAM CNIT = proposition at IETF 91 > =20 > Hi Richard, >=20 > 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? :-) >=20 > --tony >=20 > On 2014-08-20 9:10 PM, Richard Shockey wrote: > IMHO any reasonable deployment scenario for whatever we call this = would end up being part of some other SDO=92s 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 =91Policy Considerations=92 but beyond that we are out of our = league. > =20 > -- > ________________________________ >=20 > Tony Rutkowski >=20 > EVP, Industry Standards & Regulatory Affairs >=20 > tony@yaanatech.com >=20 > Yaana Technologies LLC >=20 > 542 Gibraltar Drive >=20 > Milpitas CA 95035 USA >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_5F27FDE0-26FC-49D3-B5EF-6CF1C7F8D708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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=92s 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, = =85

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

Brian

O= n Aug 27, 2014, at 12:35 PM, Richard Shockey <richard@shockey.us> = 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=92s 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:cnit-bounces@ietf.org] On Behalf Of Tony = Rutkowski
Sent: Saturday, August 23, 2014 = 4:59 PM
To: Richard Shockey; 'Michael = Hammer'; hala.mowafy@ericsson.com; = Henning.Schulzrinne@fcc.gov; dispatch@ietf.org; cnit@ietf.org
Cc: stir@ietf.org
Subject: Re: [cnit] [stir] = [dispatch] Restarting the CNAM CNIT proposition at IETF = 91
 

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:
IMHO any reasonable deployment scenario for whatever = we call this would end up being part of some other SDO=92s 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 =91Policy Considerations=92 but = beyond that we are out of our = league.
 
--

________________________________

Tony = Rutkowski

EVP, Industry Standards & Regulatory = Affairs

tony@yaanatech.com

Yaana = Technologies LLC

542 Gibraltar = Drive

Milpitas CA 95035 = USA

____________________________________________= ___
stir mailing list
stir@ietf.org
https://www.ietf.org/ma= ilman/listinfo/stir

= --Apple-Mail=_5F27FDE0-26FC-49D3-B5EF-6CF1C7F8D708--