From nobody Mon Aug 11 08:07:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834C21A0496 for ; Mon, 11 Aug 2014 08:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668] 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 lucZcynXyt3P for ; Mon, 11 Aug 2014 08:07:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E6A1A0452 for ; Mon, 11 Aug 2014 08:07:24 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7BF7DDx066257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 11 Aug 2014 10:07:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53E8DC22.30709@nostrum.com> Date: Mon, 11 Aug 2014 10:07:14 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/dIfizTy0GlVzR0duHkhc6eUzwEY Subject: [dispatch] EarlyBird registration deadline for SIPit 31 is Monday August 18 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:07:33 -0000 The Early Bird registration deadline for SIPit 31 is Monday August 18. If you haven't already registered, please do so as soon as you can. RjS > SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014. > The event will be hosted by ETSI. > > More information, and the registration page, is available at > > Please take advantage of the opportunity to register early. > > In addition to the normal team-to-team testing at the event, > we will be concentrating on several specific interoperability areas: > * Nat and Firewall Traversal using Outbound, TURN, and STUN > * RTCWeb > * Advanced Video scenarios > * Use of TLS and DTLS > > If you're planning to attend and have other areas you would like > have a multi-team focus session around, please let me know. > > RjS From nobody Mon Aug 18 10:19:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777BF1A0349 for ; Mon, 18 Aug 2014 10:19:32 -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 QNecuS475lFn for ; Mon, 18 Aug 2014 10:19:29 -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 B2E161A03EA 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/dispatch/JlYOwkEvpYYoqLq5YPlaGsaP9Ic Cc: stir@ietf.org Subject: [dispatch] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:19:32 -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:20 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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/dispatch/2FLciqtAHkaKG9uWBhqCONLkhNI Cc: "stir@ietf.org" Subject: Re: [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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 Wed Aug 20 11:46:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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/dispatch/7ETWNYdp4iDDM5z5Sa1K-ihh-gM Cc: "stir@ietf.org" Subject: Re: [dispatch] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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:16 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D141A6FD3 for ; Wed, 20 Aug 2014 12:30:15 -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 mkHQODk0yZGR for ; Wed, 20 Aug 2014 12:30:10 -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 A17BE1A06C0 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/dispatch/U0XvZYKwkq8jH0jPWCT9Thdhciw Cc: stir@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:30:15 -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:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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/dispatch/ZfS09tLwA2vtRXW71YWucJ9bcRQ Cc: "stir@ietf.org" Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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:44 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E21A00E0 for ; Wed, 20 Aug 2014 18:30:41 -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 BOsAA0XQDCdg for ; Wed, 20 Aug 2014 18:30:36 -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 78BA91A007B for ; Wed, 20 Aug 2014 18:30:33 -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/dispatch/m9hhvkxA0nujgGptlWJguWXkAx0 Cc: stir@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 01:30:41 -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:56 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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/dispatch/q8zNffoJNe8j04EtPyNCDljelJY Cc: "stir@ietf.org" Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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 07:07:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B421A02F5 for ; Thu, 21 Aug 2014 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 el-Aq_56oE-G for ; Thu, 21 Aug 2014 07:07:01 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB461A0322 for ; Thu, 21 Aug 2014 07:07:00 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-9a-53f5fd0289ac Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.1B.24955.20DF5F35; Thu, 21 Aug 2014 16:06:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 16:06:58 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: Draft new version: draft-holmberg-dispatch-iotl-02 Thread-Index: Ac+9SNGjaac4wBujTyiXIkoDVVxVSA== Date: Thu, 21 Aug 2014 14:06:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D42561B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D42561BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvjS7z36/BBkf2cVlMP/OX0WLppAWs FlP7bB2YPb48ecnksWTJTyaPyRtnsQQwR3HZpKTmZJalFunbJXBlrJ2wmrWgVaJi0SzFBsb5 ol2MnBwSAiYS+1uamSBsMYkL99azdTFycQgJHGWUuHVxBzuEs4RR4tnFa6xdjBwcbAIWEt3/ tEEaRAS0JY6u6mIGsZkFIiW+tp9jBbGFBawlLi+fygZR4yDxcfERJghbT2LF9PXsIDaLgKrE 1UknwWp4BXwlFq+4CtbLCHTE91NrmCBmikvcejIf6jgBiSV7zjND2KISLx//AztHQkBRYnm/ HER5vsTxYwuYIUYKSpyc+YRlAqPwLCSTZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQ xRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIymg1t+q+5gvPzG8RCjAAejEg9vwu+v wUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbH72qNdct8t 34gKPji+wm2m+OTgzr4yoel/3qz7F5ptvkmLI3VbOvvK/nVeGXE7IqvMPHZeO/r42dEHSz/O kAmd+KQofPvkCT73BB7JfVY/8zUnSu+EenbNBHf9pI8fd+mZFlqfWbC/UCbnWtv9p6q86eGv S2oePmH6rieb4MXSbC6Qd/yCvoMSS3FGoqEWc1FxIgAt+LzihwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/M2-fTzh9jCc0jfZ-krj5QPs4O6g Subject: [dispatch] Draft new version: draft-holmberg-dispatch-iotl-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:07:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D42561BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the IOTL draft. Based on the discussions in Toronto, the iotl parameter is now scoped to 3G= PP networks. The outcome was to progress the draft as AD sponsored, but I was requested = to submit the -02 version to DISPATCH. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D42561BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of the IOTL draft= .

 

Based on the discussions in Toronto, the iotl parame= ter is now scoped to 3GPP networks.

 

The outcome was to progress the draft as AD sponsore= d, but I was requested to submit the -02 version to DISPATCH.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D42561BESESSMB209erics_-- From nobody Thu Aug 21 10:57:57 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5F1A093B 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=unavailable 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 RSFlFRfIRKQ1 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 E54F11A0703 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/dispatch/B38JAGGl8dCht6WDceKMdsT0gI8 Cc: dispatch@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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:11:59 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@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/dispatch/q01p8kSDTB0LQCUnEcrNKVevDUA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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 Sat Aug 23 10:38:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958701A064F for ; Sat, 23 Aug 2014 10:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 YpMsE26mk9Zf for ; Sat, 23 Aug 2014 10:38:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9631A8862 for ; Sat, 23 Aug 2014 10:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1334; q=dns/txt; s=iport; t=1408815513; x=1410025113; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/VsRHMqoIbJn72E31u4elx557eEJMmA1Fnd77Jq2CsU=; b=l/cOHqPkqF9MGZZREYTwrjGFQMIB2TWfYYYi0rUrBtFzewI/KBf/V92q NsYJXWRd3+HjYM52eUarDJxnTgRUc7oooB4MwUAVZCOEiiTnwz7LA06MF QR5APhhp7b3b4+g4jrI8HFvTR5RdQIMYdPc4ichxSOUyjdDPWwfYs2wbA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFABbR+FOtJA2E/2dsb2JhbABZgmojgS7VMhZ3hAqBCwGBACcEiFUBoCWjbheTAoEdBZEmiyOVDINegjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,387,1406592000"; d="scan'208";a="71777216" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 23 Aug 2014 17:38:33 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7NHcWO8014810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 23 Aug 2014 17:38:32 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 12:38:32 -0500 From: "Cullen Jennings (fluffy)" To: DISPATCH Thread-Topic: Review of draft-jimenez-p2psip-coap-reload-04 Thread-Index: AQHPvvkO3uHgCUuhO0Kh650gEi935Q== Date: Sat, 23 Aug 2014 17:38:31 +0000 Message-ID: <1D1C6384-E5C0-4770-928A-D7575F08305D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/uBgFqypsp6sYxJ8ph8VskDVy20s Subject: [dispatch] Review of draft-jimenez-p2psip-coap-reload-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 17:38:37 -0000 This is an excellent draft and I support it=92s publication but I think the= re are a few little details to clean up first.=20 The informal ref to 3621 should be removed.=20 Section 9 talks about the associated URI in the signers certificate. I thin= k it would be good to a bit more specific about what exactly this is. Would= be a URI type entry in the SubjectAltName? I think section 10 needs a few more paragraphs. The high level pointsI I wo= uld want to have covered are=20 - all the consideration in both Reload and Coap apply here - the caching means that the values of the sensor that get cached will be s= tored on some random node in the overlay and thus readable by that node. As= peer come and go, different nodes will get the data. So at some level, all= the nodes in the overlay need to be trusted to see this information. Cachi= ng can not be used unless the threat model is such that it OK for any node = to see the cached data. There are many use cases where either all the nodes= in the overlay are trusted to see this data or the data public and fine fo= r the world to see so though this is an impotent consideration it is not an= issue in many cases.=20 Look forward to seeing this published - I think it has some really interest= ing uses as we move forward.=20 Cullen From michael@voip.co.uk Tue Aug 26 07:10:43 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093361A7022 for ; Tue, 26 Aug 2014 07:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 9gt04mVZqD9i for ; Tue, 26 Aug 2014 07:10:37 -0700 (PDT) Received: from mail-wi0-f175.google.com (na6sys009bog033.obsmtp.com [74.125.150.107]) by ietfa.amsl.com (Postfix) with SMTP id 428591A7000 for ; Tue, 26 Aug 2014 07:10:35 -0700 (PDT) Received: from mail-wi0-f175.google.com ([209.85.212.175]) (using TLSv1) by na6sys009bob033.postini.com ([74.125.148.12]) with SMTP ID DSNKU/yVW/Mu8sdhyS62lQ0HE7dDRj84vHpf@postini.com; Tue, 26 Aug 2014 07:10:36 PDT Received: by mail-wi0-f175.google.com with SMTP id ho1so4262096wib.14 for ; Tue, 26 Aug 2014 07:10:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OnyztwR+WAWMKuCsgUy2mikq1hcgvfE9t6p0oCDWZZw=; b=Wheqo4jIyIw7AZKiiHEKOre1B8HjkWfHIosW9r8s21zLT0jekZpUGZjpPcEhnqbRW3 1QsKojSPpivxAKZ5uW5TPciR1byf9zDQ7cxeA78xwYBWqt6SNG27xdaQp3Q9CpXZJ75e UXPkoLfyrrjrWk+xtW94uqVcR6deRQ6rYYsFsqED5XHza5lki+lmxD4jtL1+CN4hEizj zQ/HMaN7Bploj3jyh8EUyUnisiFjaznfF1AwU8PhJN4CapcvrDpORDB9Ostm8sTyvfmo VxGpd1PuBkYEdFx6SffxUxZqlDz2NZDZP8LQTzlfCFrZATinhNapy+qmqRHU4FtiveAm hv9w== X-Gm-Message-State: ALoCoQnFYMJgyB3005JMYrCyVIYph7cx4q9etRhjPg/ftApW6JQjDBJhEW8+a0/kitctc9OPf6LmLqR+WpcCO8apyWSIRtmMA4lXHs44EV37oy0E5giZE3tkxf85z+w3Jj/QqGSzqsjF X-Received: by 10.180.73.6 with SMTP id h6mr21997632wiv.65.1409062234215; Tue, 26 Aug 2014 07:10:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr21997612wiv.65.1409062234004; Tue, 26 Aug 2014 07:10:34 -0700 (PDT) Received: by 10.194.93.40 with HTTP; Tue, 26 Aug 2014 07:10:33 -0700 (PDT) In-Reply-To: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 15:10:33 +0100 Message-ID: From: Michael Procter To: IETF Dispatch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/kDwi9QFE57FCGBhFB4pQOhc_BxQ X-Mailman-Approved-At: Tue, 26 Aug 2014 07:14:31 -0700 Subject: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:11:45 -0000 Dear all, SIP Outbound (RFC5626) is a useful mechanism to allow User Agents to reliably communicate through NATs to proxies and registrars. However, there is one part of the problem that isn't addressed: how do UAs discover the edge proxies to use? The RFC leaves this to either static configuration or future discovery mechanisms. I've written a draft which discusses a simple mechanism to help SIP User Agents discover SIP proxies for use with RFC5626 (SIP Outbound). As far as I am aware, there is currently no standard approach to this. It is my hope that by defining a simple mechanism, the overall deployment of SIP Outbound can be increased, with a corresponding increase in reliability and maintainability of SIP networks. I welcome comments and feedback, not least about whether you agree that the problem exists and is worth solving! Regards, Michael ---------- Forwarded message ---------- From: Date: 4 July 2014 16:51 Subject: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt To: Michael Procter A new version of I-D, draft-procter-dispatch-outbound-discovery-00.txt has been successfully submitted by Michael Procter and posted to the IETF repository. Name: draft-procter-dispatch-outbound-discovery Revision: 00 Title: Automatic discovery of RFC 5626 Edge Proxies Document date: 2014-07-04 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-procter-dispatch-outbound-discovery-00.txt Status: https://datatracker.ietf.org/doc/draft-procter-dispatch-outbound-discovery/ Htmlized: http://tools.ietf.org/html/draft-procter-dispatch-outbound-discovery-00 Abstract: [RFC5626] (commonly known as 'SIP outbound') defines mechanisms that permit SIP (Session Initiation Protocol) UAs (User Agents) to maintain multiple connections to a registrar or proxy via multiple Edge Proxies, known as the outbound-proxy-set. Discovering the URIs that make up the outbound-proxy-set is left to configuration or future discovery mechanisms. This draft defines a simple discovery mechanism that enables UAs to discover the URIs of all the Edge Proxies in the outbound-proxy-set without requiring additional configuration on the UA. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Aug 27 09:36:13 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C851A0B78 for ; Wed, 27 Aug 2014 09:36:08 -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 nCqYSkfN8RVV for ; Wed, 27 Aug 2014 09:36:05 -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 536BE1A0B80 for ; Wed, 27 Aug 2014 09:36:05 -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/dispatch/MbhNCXe8AGm6u5BvMVz_mJse4yk Cc: stir@ietf.org Subject: Re: [dispatch] [cnit] [stir] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:36:08 -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 Wed Aug 27 14:34:29 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993E61A02A6 for ; Wed, 27 Aug 2014 14:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 NTXihmmDpy0G for ; Wed, 27 Aug 2014 14:34:27 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBBE1A0002 for ; Wed, 27 Aug 2014 14:34:27 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta01.westchester.pa.mail.comcast.net with comcast id jxN11o00517dt5G51xaSAQ; Wed, 27 Aug 2014 21:34:26 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta13.westchester.pa.mail.comcast.net with comcast id jxaR1o00N1KKtkw3ZxaSur; Wed, 27 Aug 2014 21:34:26 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s7RLYN15026387; Wed, 27 Aug 2014 17:34:24 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s7RLYMMS026386; Wed, 27 Aug 2014 17:34:22 -0400 Date: Wed, 27 Aug 2014 17:34:22 -0400 Message-Id: <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Procter In-reply-to: (michael@voip.co.uk) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409175266; bh=CGRV1gmWUzHhQY1qoKnL8dTewC14JvnY9QD/BLJ+6UA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=VqxG/hfasQRGFecsTx+c68QIXnQ/zezZhG+eBYxrBp6vT5gWwIuvqJkzSFwgENwB1 Z9PqUKOuZ8Xzhy3IKRhFg5NxVvBqBJhuuZrjd2pr2kyed0sghddTnBFVDrXQ2Nq+t4 2Xc5xLgGj5T81QO7RfTmpnXwJZr7fm0Q3H528ZLlqnEQs9eWR+CHwBAIuocYxNpitJ voukRTgYPDNJ6Mxt2eB0B1jwqB+TAwLMtF0CegjoviXPi8PVdr7TP0RaDGNiBkshPl TGgbqiFdrLv15tanwOhWzDSREZlbX2icGdUefJ1evItTJNXNFNOswjnl0ef5uvUk8g eDZpBlXsAabqw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/KG0ZxuFlb0C3HFWQPUjEDXUt9Zs Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 21:34:28 -0000 > From: Michael Procter > I welcome comments and feedback, not least about whether you agree > that the problem exists and is worth solving! Certainly the functionality is needed. But what I don't see is why the ordinary use of RFC 3263 and DNS SRV records does not suffice. That has been the practice in systems that I've seen: You arrange for phones in the "outside universe" to see a set of SRV records that list the available edge proxies, and the phone attempts to establish one or more connections through one or more of the proxies. This establishment "just happens" when the phone attempts to send its REGISTER to the DNS name of its SIP domain. That is, no extra functionality is needed if the phone supports SRV records per RFC 3263. (And we specify with the system that the phones must support SRV records.) Dale From nobody Thu Aug 28 00:52:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D547F1A0704 for ; Thu, 28 Aug 2014 00:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 w1yloGixtUwp for ; Thu, 28 Aug 2014 00:52:02 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BD51A0701 for ; Thu, 28 Aug 2014 00:52:01 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so355631wgg.32 for ; Thu, 28 Aug 2014 00:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sn8lcvtJ2Sf8KU0QEa+JV3erQm8KQq1UeotTtltJX18=; b=dAlik8lL0xrCZOS4YnTSOdryyCXqHedM6E5efyRD+MNssmRefI6dA58bMem4D989kX 1DbfEI/2ngu4bJAQdMEEWHWDSYKehwrkyMBK4c1B6K4Xtqz2vVHkK600myZTFoF5Y+dF j4cUhyV+J8X3wjWdfeVmjfFIQKLg4rWjKo0/UtkbcW5kym4t2myN0fmZHwibL/jwEo8V 5jZXCfyycMKF/MkSGscQdJ3StXYW0QUnEmZup83Qwk8pZsQ4Ser2Mlm8OVvWRaS5g28i C5vYmSA5hFRhiv1CywAJDFNV22ODZzqXUYmF/bd21EoLdBjOD9CowH8mNRvjBUKfTbnn TLng== MIME-Version: 1.0 X-Received: by 10.180.207.105 with SMTP id lv9mr3755528wic.23.1409212320275; Thu, 28 Aug 2014 00:52:00 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Thu, 28 Aug 2014 00:52:00 -0700 (PDT) In-Reply-To: <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> Date: Thu, 28 Aug 2014 08:52:00 +0100 Message-ID: From: Michael Procter To: "Dale R. Worley" , dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a11c3f956c365750501abcfb8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XljwsdwAf-4AObMFH2JG0tQdH0s Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 07:52:04 -0000 --001a11c3f956c365750501abcfb8 Content-Type: text/plain; charset=UTF-8 HI Dale, Thanks for your comments. On Wed, Aug 27, 2014 at 10:34 PM, Dale R. Worley wrote: > Certainly the functionality is needed. But what I don't see is why > the ordinary use of RFC 3263 and DNS SRV records does not suffice. > That has been the practice in systems that I've seen: You arrange for > phones in the "outside universe" to see a set of SRV records that list > the available edge proxies, and the phone attempts to establish one or > more connections through one or more of the proxies. This > establishment "just happens" when the phone attempts to send its > REGISTER to the DNS name of its SIP domain. > My understanding of RFC 3263 is that in this scenario, a phone attempts to maintain only one registration, and subsequent re-registrations may be directed randomly between the SRV targets (following priority and weighting rules). This is consistent with the behaviour of a number of vendors' UAs that I see. I agree that using the list of advertised SRV targets as a list of outbound-proxies should work, and that is the basic approach used in the draft. As far as I am aware, there is currently no document describing this approach, which is why I wrote the draft. Best regards, Michael --001a11c3f956c365750501abcfb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HI Dale,

Thanks for your comments.

On Wed, Aug 27, 2014 at 10:34 = PM, Dale R. Worley <worley@ariadne.com> wrote:
Certainly the functionali= ty is needed.=C2=A0 But what I don't see is why
the ordinary use of RFC 3263 and DNS SRV records does not suffice.
That has been the practice in systems that I've seen:=C2=A0 You arrange= for
phones in the "outside universe" to see a set of SRV records that= list
the available edge proxies, and the phone attempts to establish one or
more connections through one or more of the proxies.=C2=A0 This
establishment "just happens" when the phone attempts to send its<= br> REGISTER to the DNS name of its SIP domain.

= My understanding=20 of RFC 3263 is that in this scenario, a phone attempts to maintain only=20 one registration, and subsequent re-registrations may be directed=20 randomly between the SRV targets (following priority and weighting=20 rules).=C2=A0 This is consistent with the behaviour of a number of vendors&= #39;=20 UAs that I see.

I agree that using the list of advertised SRV targets as a list of outbound-proxies should work, and that is the basic approach=20 used in the draft.=C2=A0 As far as I am aware, there is currently no docume= nt describing this approach, which is why I wrote the draft.
=C2=A0
Best regards,

Michael
--001a11c3f956c365750501abcfb8-- From nobody Thu Aug 28 05:18:35 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD751A0385 for ; Thu, 28 Aug 2014 05:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 id18H3Q4JBHt for ; Thu, 28 Aug 2014 05:18:32 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C72D1A03AC for ; Thu, 28 Aug 2014 05:18:29 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id mc6so818411lab.9 for ; Thu, 28 Aug 2014 05:18:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bhjJiFiAVdi07UAPIWx89nwFrbH8TdPvrGKkyIQCZmc=; b=Go3chyKXpxxV982SwHugPLk+ctsLDpHEL2hGarcZeVY1HZIL4GQ/iDruNFvu6AlEDg ML3IgH3qpgNL7mEMS1tvXpuwjYmDBTz5qazNygwRKmIvHniT6lyF4yiqwRtwWKH6aWX+ IIw0OnUzEtSj9uHoB4x/D7wjGnouiwWLLfykkkUtDnIr+vr7yt7TGM+HbjJ6K8ONGage QdmouTD5mahHeHjRN37YBypMkbRizSIMxO8srShGjZsVclWQ0ndaRBdEuPgA1IKcfU/y dLglC7aq7Coxq9k6zG7ASqsbJJ1NTchQ+XCihDDoB8Xp+1hmhtP8PwyHNJUEjm70Sd8c Y4oQ== X-Gm-Message-State: ALoCoQkGRkNE8wbfSrkVU1SNsXA3NtI6vIiVMH+tDwrxPfYj0abzBR6OR+x5XtVH04hzJAebySvH MIME-Version: 1.0 X-Received: by 10.112.35.97 with SMTP id g1mr3865263lbj.20.1409228304363; Thu, 28 Aug 2014 05:18:24 -0700 (PDT) Received: by 10.25.135.10 with HTTP; Thu, 28 Aug 2014 05:18:24 -0700 (PDT) In-Reply-To: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> Date: Thu, 28 Aug 2014 08:18:24 -0400 Message-ID: From: Simon Perreault To: Michael Procter Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/l36-FInth4LsKmrz3-oK2Ih8rNA Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:18:34 -0000 On Thu, Aug 28, 2014 at 3:52 AM, Michael Procter wrote: > I agree that using the list of advertised SRV targets as a list of > outbound-proxies should work, and that is the basic approach used in the > draft. As far as I am aware, there is currently no document describing this > approach, which is why I wrote the draft. Does anyone well versed in IETF lore remember why this seemingly obvious approach was not defined in RFC 5626? It appears too easy, and things are never easy with SIP... Simon From nobody Thu Aug 28 06:54:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC3F1A0475 for ; Thu, 28 Aug 2014 06:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Ak-xMGp-7FOM for ; Thu, 28 Aug 2014 06:53:57 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CC81A0422 for ; Thu, 28 Aug 2014 06:53:56 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id z12so777080wgg.18 for ; Thu, 28 Aug 2014 06:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jG+DessNWkscEJcJTMCDkIFJf/TyP+pdVgh6RS4vXB0=; b=M1j1sdxPRoL9QOggGQW8oqzGO/dUo1hYHGdyhkaJ9oeiyhe+iolc8U3SMvQjNjT9iU eIWqcVzZV21K1fIQH7UUyeDHf/UGf7evMuf2j+0Loh3pT9JdFTIPka90tUpmauIY/yLX rKrHYmi+Sx/PzDr8YLutNDqd1abzQpP4BkCvSBIhzYERMGE8cAKrvYQRI0tylcAOMi5s ITD1Uy9+2VLD+DA3ita2HuBdTT4U+PHPLKdxLisstOBoklkmOzcS3eLo6jVu/gPRr4uH vDox8wN4Ab8ti8UyoN2qtvCxSX58LLf+gBfiuafZewR+OfmJtyxCnc4MVi/CbhiIItL7 bzsA== MIME-Version: 1.0 X-Received: by 10.180.208.111 with SMTP id md15mr6223672wic.3.1409234034131; Thu, 28 Aug 2014 06:53:54 -0700 (PDT) Received: by 10.194.39.231 with HTTP; Thu, 28 Aug 2014 06:53:54 -0700 (PDT) In-Reply-To: References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> Date: Thu, 28 Aug 2014 14:53:54 +0100 Message-ID: From: Michael Procter To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c382ca028d620501b0deab Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/GC6rqZVrgPJLyfFfOU4_PuNIAcQ Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:54:01 -0000 --001a11c382ca028d620501b0deab Content-Type: text/plain; charset=UTF-8 On Thu, Aug 28, 2014 at 1:18 PM, Simon Perreault wrote: > On Thu, Aug 28, 2014 at 3:52 AM, Michael Procter > wrote: > > I agree that using the list of advertised SRV targets as a list of > > outbound-proxies should work, and that is the basic approach used in the > > draft. As far as I am aware, there is currently no document describing > this > > approach, which is why I wrote the draft. > > Does anyone well versed in IETF lore remember why this seemingly > obvious approach was not defined in RFC 5626? It appears too easy, and > things are never easy with SIP... > > Simon > Interestingly, draft-jennings-sipping-outbound-01[0] contains a paragraph: A UA that needs to establish multiple flows needs a way to use DNS to select candidate addresses for the formation of flows. The recommended way to do this is to look at the DNS records resulting from the algorithm described in RFC 3263 [3] and select distinct addresses from the target set. But the next revision (draft-ietf-sip-outbound-00[1]) removes this and has a changelog comment of: Changed to use a configured set of backup proxies instead of playing DNS games to try and figure out what backup proxies to use. I have searched both the sip and sipping list archives over the relevant timeframe (Feb 2005 to July 2005) and can't find any mention of the change. The minutes of the sip meeting at IETF62[2] contain no reference to this part either. The conclusion I draw is that it was removed keep things simple, given that at the time the config framework was almost complete and would provide a general solution to all these configuration issues. Maybe someone else can remember if there were other questions raised at the time? Regards, Michael [0] http://www.ietf.org/archive/id/draft-jennings-sipping-outbound-01.txt [1] http://tools.ietf.org/id/draft-ietf-sip-outbound-00.txt [2] http://www.ietf.org/proceedings/62/sip.html --001a11c382ca028d620501b0deab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 28, 2014 at 1:18 PM= , Simon Perreault <sperreault@jive.com> wrote:
On Thu, Aug 28, 2014 at 3:52 AM, Michael Procter <michael.ietf@gmail.com> wrote: > I agree that using the list of advertised SRV targets as a list of
> outbound-proxies should work, and that is the basic approach used in t= he
> draft.=C2=A0 As far as I am aware, there is currently no document desc= ribing this
> approach, which is why I wrote the draft.

Does anyone well versed in IETF lore remember why this seemingly
obvious approach was not defined in RFC 5626? It appears too easy, and
things are never easy with SIP...

Simon

Interestingly, draft-jennings-sipping-= outbound-01[0] contains a paragraph:

=C2=A0 =C2=A0A UA that needs to= establish multiple flows needs a way to use DNS to
=C2=A0 =C2=A0select = candidate addresses for the formation of flows. =C2=A0The
=C2=A0 =C2=A0recommended way to do this is to look at the DNS records resul= ting
=C2=A0 =C2=A0from the algorithm described in RFC 3263 [3] and selec= t distinct
=C2=A0 =C2=A0addresses from the target set.

But the ne= xt revision (draft-ietf-sip-outbound-00[1]) removes this and has a changelo= g comment of:

=C2=A0 =C2=A0Changed to use a configured set of backup proxies instead = of playing
=C2=A0 =C2=A0DNS games to try and figure out what backup prox= ies to use.

I have searched both the sip and sipping list archives o= ver the relevant timeframe (Feb 2005 to July 2005) and can't find any m= ention of the change. =C2=A0The minutes of the sip meeting at IETF62[2] con= tain no reference to this part either.

The conclusion I draw is that it was removed keep things simple, given = that at the time the config framework was almost complete and would provide= a general solution to all these configuration issues. =C2=A0Maybe someone = else can remember if there were other questions raised at the time?

Regards,

Michael

[0] http://www.ietf.org/archive/i= d/draft-jennings-sipping-outbound-01.txt
[1] http://tools.ietf.org/id/draft= -ietf-sip-outbound-00.txt
[2] http://www.ietf= .org/proceedings/62/sip.html
--001a11c382ca028d620501b0deab-- From nobody Thu Aug 28 14:14:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D658D1A049A 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.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=unavailable 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 PpYpbVHBYIgE for ; Thu, 28 Aug 2014 14:14:34 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5651A0127 for ; Thu, 28 Aug 2014 14:14:34 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so1496095qcx.13 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=bOjsWvsuGXD8+gkI6XyJk/WbYIlXiLfLmecUdnRoDaGjAmO5JGekq9rA4GG9bi24C3 p25uOByC+iRCg3itmOsdkMyyhDGpco1a10SVs5XA1sZjqbv+Gmv5Tiab2T6actn7PdV/ Iubn+dWjN9Kbi4XD1g9+ZWmD1favJ0fvOAEYDEAS2mkzkL2WrmQpeZ+8i8i5P62vPjoL lJxyaZ0QWf0QX7woTLpN+0MHlOkLl2Zw7tKblQmoiNAAZ5VySZz2cxew4PlMTlPwxpfF M2SrqQ7iymQWVQ+w4yassOpBwh7fExNXX87SXda3t6Z7kxD0uIeR0YjzAzj5mXl6R5Ep lyqg== X-Gm-Message-State: ALoCoQm6hqA/+QPP4IFX9l5S/olmgTsUU0R9Ds6fHcwG/jCYrhVG4to5oNFgZMpH77d3Rs9+BRUJ 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/dispatch/SnGBPDxugwgcBd53j8OfPLEUi6E Cc: hala.mowafy@ericsson.com, dispatch@ietf.org, tony@yaanatech.com, cnit@ietf.org, stir@ietf.org Subject: Re: [dispatch] [stir] [cnit] Restarting the CNAM CNIT proposition at IETF 91 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail 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-- From nobody Fri Aug 29 11:36:20 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F279D1A0ACE for ; Fri, 29 Aug 2014 11:36:17 -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 7U0yKMf-AJzz for ; Fri, 29 Aug 2014 11:36:17 -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 C739E1A0AE4 for ; Fri, 29 Aug 2014 11:35:02 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id kf7C1o0050SCNGk56ib2Jg; Fri, 29 Aug 2014 18:35:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta09.westchester.pa.mail.comcast.net with comcast id kib11o00K3Ge9ey3Vib1wC; Fri, 29 Aug 2014 18:35:02 +0000 Message-ID: <5400C7D5.3080502@alum.mit.edu> Date: Fri, 29 Aug 2014 14:35:01 -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: dispatch@ietf.org References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> 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=1409337302; bh=VluC525luvy7rViku01ZiUhjqFF/gXPpmbNs8Zhl4/Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DMtpFyk+qb0b1dTsZM8AiEe6Pi0kkZ/UYBXL8KZoiBzXrE8fZ4V75lB36eHvasXlO DNzJtkDZ5QOpIz06ONj2ea/Z6MnsqWvCW8ez0dVwHMu8jTdSz/BIMPa2tFeR4euDBR CZY9mw2Pi1KCvBGUA4b04mI6omNJSHXIewS/M+2dQz/Qs5of0KJXdwoOnTc0sBgeNK sHWkeJCSxXSS9MuhhLSNWdkhN4GKTLNBkqSOmm5n0oCTIbYxs0C5SAHWI/Px8VuKVk oce+Gm4Ybsf7EPLVFvxsEkm8OMK3AVHVmZWqQAj9Cp2WKiAz/WWnDgFRFmPw63RmIh libTwOXYOt/TQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/mioKvtKKmiikxOO2GOocDu8bXoQ Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:36:18 -0000 Michael, Thanks for bringing this up. Were it to be adopted, it seems clear to me that it would be handled within sipcore. I'm happy to discuss it on the sipcore list, and if there is interest, we can probably bypass dispatch. More inline. On 8/28/14 3:52 AM, Michael Procter wrote: > HI Dale, > > Thanks for your comments. > > On Wed, Aug 27, 2014 at 10:34 PM, Dale R. Worley > wrote: > > Certainly the functionality is needed. But what I don't see is why > the ordinary use of RFC 3263 and DNS SRV records does not suffice. > That has been the practice in systems that I've seen: You arrange for > phones in the "outside universe" to see a set of SRV records that list > the available edge proxies, and the phone attempts to establish one or > more connections through one or more of the proxies. This > establishment "just happens" when the phone attempts to send its > REGISTER to the DNS name of its SIP domain. > > > My understanding of RFC 3263 is that in this scenario, a phone attempts > to maintain only one registration, and subsequent re-registrations may > be directed randomly between the SRV targets (following priority and > weighting rules). This is consistent with the behaviour of a number of > vendors' UAs that I see. > > I agree that using the list of advertised SRV targets as a list of > outbound-proxies should work, and that is the basic approach used in the > draft. As far as I am aware, there is currently no document describing > this approach, which is why I wrote the draft. IMO the validity of using alternatives from the SRV lookup in parallel for concurrent registrations is questionable. ISTM it is at least outside the intended usage. Using explicit negotiation for doing so, as this draft proposes, is one way clear that up. I have considered another way of achieving this end: - the UA starts with the To-Uri it wants to register to: say sip:example.com - the UA uses that to form an initial REGISTER request. The same URI becomes the R-URI. The REGISTER is set up consistent with RFC5626. - the R-URI is resolved "normally" according to 3263, and the request is sent. - the server that is reached notes that the request wants to use 5626, but has been received with the "default" R-URI. It decides that redundant registration is desired. - the server responds with a 3xx containing contacts of redundant registrars or proxies to the registrar. This could be either 302 (moved temporarily) if redundant registrars are desired, or 305 (use proxy) if the goal is to use redundant proxies to a common registrar. - For a 302 response, the UA then retries the request with multiple redundant registrations using contacts from the 302 in To-URI and R-URI. - For a 305 response, the UA then retries the request with multiple redundant registrations, with the old To-URI, but with a URIs from the 305 Contact either as the R-URI or in a Route header. One issue with this approach arises if TLS is being used, because the contacts in the 3xx must be different from the original R-URI. (3261: a client processing 3xx class responses MUST NOT add any given URI to the target set more than once.) This can be expensive in TLS setup. I think it can be avoided with care. The original servers can have multiple srv records - (e.g., both registrar.example.net and registrar-1.example.net) that resolve to the same IP address. With proper credential management the same connection should be usable for both. But this mechanism is certainly more complex, both to set up and to use, than what Michael has proposed. Thanks, Paul From nobody Fri Aug 29 13:56:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AA31A6FA1 for ; Fri, 29 Aug 2014 13:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 UAvxd7E1i36C for ; Fri, 29 Aug 2014 13:56:34 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 52C441A00DB for ; Fri, 29 Aug 2014 13:56:34 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id kkcM1o0011ap0As55kwZAW; Fri, 29 Aug 2014 20:56:33 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id kkwZ1o00D1KKtkw3ikwZN7; Fri, 29 Aug 2014 20:56:33 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s7TKuWP7015950; Fri, 29 Aug 2014 16:56:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s7TKuWok015949; Fri, 29 Aug 2014 16:56:32 -0400 Date: Fri, 29 Aug 2014 16:56:32 -0400 Message-Id: <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Michael Procter In-reply-to: (michael.ietf@gmail.com) References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409345793; bh=uhxvNrDDqVJevyXI+ruCOYXZJp+L6B3Jd4Kd7NDfKJQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=Vcr0wbMDWAa6mUEzllVmzcbwedWBkzWkkXP7XLyULavRPq4ruaKPGLRFOWTzNI/1C 6ttP5KDO0WOJ7R6SsTF2vLMSMOcdv08o/U8Ms95mVycQ0K4ZheRk5TMwBl63yptm/1 wHlWaJSePcQtUgsrPOPHK6xiOn5dPbT3e658w325Ev7TBRwIkGwIDxvZpiPJpIfkmI Dafg6iUoDsRmgAsXMk4VBnr+NRaH+E2G6nzxUI5bTdxK3hVEiFLYwoaKl9ekncQCct K+CEWwXlQcVoDp34wb0bTYu3pqTqo58BOqdFmT5z0Tdva/g+BK0kKrWsQfPF7CW9LW GOeP9q96OvpOw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zh7E0o5KIHXFug6ZBVuKX9J4v1c Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 20:56:36 -0000 > From: Michael Procter > > Certainly the functionality is needed. But what I don't see is why > > the ordinary use of RFC 3263 and DNS SRV records does not suffice. > > That has been the practice in systems that I've seen: You arrange for > > phones in the "outside universe" to see a set of SRV records that list > > the available edge proxies, and the phone attempts to establish one or > > more connections through one or more of the proxies. This > > establishment "just happens" when the phone attempts to send its > > REGISTER to the DNS name of its SIP domain. > > My understanding of RFC 3263 is that in this scenario, a phone attempts to > maintain only one registration, and subsequent re-registrations may be > directed randomly between the SRV targets (following priority and weighting > rules). This is consistent with the behaviour of a number of vendors' UAs > that I see. I've looked at Outbound (RFC 5626) a bit, but am no expert. I've always thought that if a phone supported Outbound, it would do so by taking the top SRV choice and sending a REGISTER. If the registrar responded indicating it supported Outbound, the phone would take successive SRV choices to establish additional flows. How the phone, the registrar, and the edge proxy negotiate whether to use Outbound is described in RFC 5626 section 4.2 -- that is, assuming that everyone understands that *if* Outbound is to be used, *either* the outbound-proxy-set is to be taken from DNS *or* the administrative authority responsible for the DNS has configured the phone by some other means. > I agree that using the list of advertised SRV targets as a list of > outbound-proxies should work, and that is the basic approach used in the > draft. As far as I am aware, there is currently no document describing > this approach, which is why I wrote the draft. I think that what I see is that there is no need for a new negotiation mechanism, because the mechanisms of RFC 5626 already work. But there *is* a need to describe the use of SRV records to provide the outbound-proxy-set -- it's "obvious" and understood, but not actually documented. (There is no need for additional negotiation, because how the administrator of the phone has configured it already tells it where to get the outbound-proxy-set.) Dale From nobody Fri Aug 29 15:01:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9371A6FE5 for ; Fri, 29 Aug 2014 15:01:31 -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 OQaZGX1aGcqo for ; Fri, 29 Aug 2014 15:01:30 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 818831A6F75 for ; Fri, 29 Aug 2014 15:01:29 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id klv91o0031YDfWL55m1Ud6; Fri, 29 Aug 2014 22:01:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta20.westchester.pa.mail.comcast.net with comcast id km1U1o00U3Ge9ey3gm1Ujl; Fri, 29 Aug 2014 22:01:28 +0000 Message-ID: <5400F838.9060000@alum.mit.edu> Date: Fri, 29 Aug 2014 18:01:28 -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: dispatch@ietf.org References: <20140704155153.17916.76121.idtracker@ietfa.amsl.com> <201408272134.s7RLYMMS026386@hobgoblin.ariadne.com> <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> In-Reply-To: <201408292056.s7TKuWok015949@hobgoblin.ariadne.com> 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=1409349688; bh=tgZW77wSSDVnEp0PFRn8kgPkTdUsqvz/1xF//lMnwdg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s2dfctef1H6GVmCEN/HDV9nBGBXt+rKSrbEWokqGL2A+YDyIApsUelq075wwcJV1A 97saVvO6GsrrUuiH4aHYX0L+Wgqk8TVxRLGewN1ALjDkDFMEww2Og9HHmWJ8Yz77x6 wM+tcmCn2XDoFRbX6MiRhxfn+StY27nVmVv8MOD5LrvNX4I/P8TSrFnnWdmWYXXQZZ m5tskImGHDXzbnpdfpD5xlbf5nNH7WQinVZSXVgoUDdheFSkHwrqEVngkci3HQoJG/ dwLmkeyKJHNEXmF+6qgvP5g3WZiYqAJsD51/cvBdRsu+kJPej3EsRt93KCB+1/kdzS IgJYsMic86+WA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/2ycBLwP-XtyAOvSf8PwJCu4bTbc Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 22:01:32 -0000 On 8/29/14 4:56 PM, Dale R. Worley wrote: >> From: Michael Procter > >>> Certainly the functionality is needed. But what I don't see is why >>> the ordinary use of RFC 3263 and DNS SRV records does not suffice. >>> That has been the practice in systems that I've seen: You arrange for >>> phones in the "outside universe" to see a set of SRV records that list >>> the available edge proxies, and the phone attempts to establish one or >>> more connections through one or more of the proxies. This >>> establishment "just happens" when the phone attempts to send its >>> REGISTER to the DNS name of its SIP domain. >> >> My understanding of RFC 3263 is that in this scenario, a phone attempts to >> maintain only one registration, and subsequent re-registrations may be >> directed randomly between the SRV targets (following priority and weighting >> rules). This is consistent with the behaviour of a number of vendors' UAs >> that I see. > > I've looked at Outbound (RFC 5626) a bit, but am no expert. I've > always thought that if a phone supported Outbound, it would do so by > taking the top SRV choice and sending a REGISTER. If the registrar > responded indicating it supported Outbound, the phone would take > successive SRV choices to establish additional flows. > > How the phone, the registrar, and the edge proxy negotiate whether to > use Outbound is described in RFC 5626 section 4.2 -- that is, assuming > that everyone understands that *if* Outbound is to be used, *either* > the outbound-proxy-set is to be taken from DNS *or* the administrative > authority responsible for the DNS has configured the phone by some > other means. > >> I agree that using the list of advertised SRV targets as a list of >> outbound-proxies should work, and that is the basic approach used in the >> draft. As far as I am aware, there is currently no document describing >> this approach, which is why I wrote the draft. > > I think that what I see is that there is no need for a new negotiation > mechanism, because the mechanisms of RFC 5626 already work. But there > *is* a need to describe the use of SRV records to provide the > outbound-proxy-set -- it's "obvious" and understood, but not actually > documented. > > (There is no need for additional negotiation, because how the > administrator of the phone has configured it already tells it where to > get the outbound-proxy-set.) ISTM that the *minimum* that a UA needs to have configured for itself is an AOR. From the AOR it can derive a URI of the corresponding registrar by removing the user part. Are you assuming *that* is then what is used as the URI for the outbound proxy set? Or are you assuming some other URI is configured, that is expected to identify an outbound-proxy-set? If the UA is starting with just an AOR, without any expectation of whether the registrar supports outbound, then it is at least a bit tricky. A registrar that doesn't support outbound isn't going to be happy with multiple simultaneous registrations to multiple servers for its domain. Dale - your proposal is that if a single registration receives an indication of outbound support, then we can infer that other servers from DNS can be used that way. That seems plausible. It is *possible* that it is inconsistent with deployed implementations of outbound. I suspect there are few enough of those that we can just ask. Thanks, Paul