Re: [cnit] CNIT Charter bashing..

"Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com> Sun, 14 June 2015 17:58 UTC

Return-Path: <timothy.dwight@verizon.com>
X-Original-To: cnit@ietfa.amsl.com
Delivered-To: cnit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E01B3076 for <cnit@ietfa.amsl.com>; Sun, 14 Jun 2015 10:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.101
X-Spam-Level:
X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoeh8S_iFdit for <cnit@ietfa.amsl.com>; Sun, 14 Jun 2015 10:58:37 -0700 (PDT)
Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AF11B3073 for <cnit@ietf.org>; Sun, 14 Jun 2015 10:58:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1434304718; x=1465840718; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/lUlbqndxlZp/mwt7qPTsY3bMgsmCdpF44EwfTb7E98=; b=mAzFEGpdYriu9aT6QyPIQak7fIaWuOZawSdnC2iG1kT7RGnadze6aYGK 7bW51UL8TKAinQEXDFNioVAdrMrXdee4U7AARZvbRvcFhzA9lyn5KnW2t hM/FrZdDfbi9VoJF6YvE+9hGMEHrCbOtTb40osNpvAU2YM5biphRkeiCS 8=;
X-IronPort-Anti-Spam-Filtered: false
Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 14 Jun 2015 17:58:25 +0000
From: "Dwight, Timothy M (Tim)" <timothy.dwight@verizon.com>
X-IronPort-AV: E=Sophos;i="5.13,614,1427760000"; d="scan'208";a="1019132201"
Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi02.verizon.com with ESMTP; 14 Jun 2015 17:58:25 +0000
Received: from FHDP1LUMXC7V31.us.one.verizon.com ([166.68.125.32]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Sun, 14 Jun 2015 13:58:24 -0400
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Date: Sun, 14 Jun 2015 13:58:20 -0400
Thread-Topic: [cnit] CNIT Charter bashing..
Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAB9cAgAAPTgCAABkwgP//7x3tADGHMBAAITkHRAAICivQ
Message-ID: <2B0F677F0B95454297753F58D4A07FA30279326EC8@FHDP1LUMXC7V31.us.one.verizon.com>
References: <D19F23AD.26CEA%richard@shockey.us> <E42CCDDA6722744CB241677169E8365603614617@MISOUT7MSGUSRDB.ITServices.sbc.com> <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <E6A16181E5FD2F46B962315BB05962D07D354C94@fcc.gov> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <D1A05A04.26E84%richard@shockey.us> <E6A16181E5FD2F46B962315BB05962D07D355543@fcc.gov> <557AE9E4.5030205@cs.tcd.ie> <D1A0761F.26EE1%richard@shockey.us> <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net> <2B0F677F0B95454297753F58D4A07FA30279326B72@FHDP1LUMXC7V31.us.one.verizon.com> <53A932AB-5E5D-41C0-895F-21EC1D4B17D5@brianrosen.net>, <2B0F677F0B95454297753F58D4A07FA30279326CB7@FHDP1LUMXC7V31.us.one.verizon.com> <E6A16181E5FD2F46B962315BB05962D07D3558A5@fcc.gov>, <2B0F677F0B95454297753F58D4A07FA30279326E8D@FHDP1LUMXC7V31.us.one.verizon.com> <E6A16181E5FD2F46B962315BB05962D07D35C213@fcc.gov>
In-Reply-To: <E6A16181E5FD2F46B962315BB05962D07D35C213@fcc.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cnit/5de8aYlzXqPy_i5zRnPJfGKq-UA>
Cc: "cnit@ietf.org" <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..
X-BeenThere: cnit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Calling Name Identity Trust discussion list <cnit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cnit>, <mailto:cnit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cnit/>
List-Post: <mailto:cnit@ietf.org>
List-Help: <mailto:cnit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cnit>, <mailto:cnit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jun 2015 17:58:39 -0000

Henning,

I'm not sure 'carrier B' would in the "in-band case" have no incentive to use a 3rd party service.  It might be that the 3rd party service provides additional information and/or is considered more trustworthy than whoever provided the in-band information.  We can (and I hope will) change the incentives.  I think it would be a reasonable objective to carry whatever content is deemed "necessary" to serve the public, in-band.  If people want to operate databases full of calling party's cat pictures, and Carrier B wants to provide this to their customer (or allow their customer to obtain it themselves, e.g., provide them a link to it) that's all OK with me.

I agree with you about the importance of being able to know unambiguously, who inserted the information.

Tim


-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] 
Sent: Sunday, June 14, 2015 8:55 AM
To: Dwight, Timothy M (Tim)
Cc: cnit@ietf.org
Subject: RE: [cnit] CNIT Charter bashing..

Just to clarify: For the lawyer remark, I meant the future in-band scenario. I agree that under the current mode of operation, you'd need a private detective, not a lawyer. In the in-band case, carrier B would have no incentive to use a third-party service, so a call from a number assigned to Verizon would always have caller name from Verizon (however they created it).

The idea is that you don't need perfect validation if you can easily track down who inserted the information. If the information is maliciously wrong, it becomes feasible to use non-technical means to correct the information. 

Henning

________________________________________
From: Dwight, Timothy M (Tim) [timothy.dwight@verizon.com]
Sent: Saturday, June 13, 2015 6:47 PM
To: Henning Schulzrinne; Brian Rosen
Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard Shockey
Subject: RE: [cnit] CNIT Charter bashing..

Henning,

I appreciate, and mostly agree with, your comments below.  Please see additional thoughts inline.

tim

-----Original Message-----
From: cnit [mailto:cnit-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Friday, June 12, 2015 5:28 PM
To: Dwight, Timothy M (Tim); Brian Rosen
Cc: philippe.fouquart@orange.com; cnit@ietf.org; Stephen Farrell; Richard Shockey
Subject: Re: [cnit] CNIT Charter bashing..

Today's CNAM display has three problems:

(1) It is unclear to the recipient how the data got inserted and by whom. There is no realistic way for the callee to find out - good luck calling your phone company consumer support line and asking about CNAM database dips.

[tmd] People do call their service provider's "support line" about issues with calling name, and we do help them.  Nobody will claim that that's easy though.  The information can be obtained in various ways from various sources.  The proliferation of non-authoritative calling name databases sometimes leads to disputes over "whose data is correct", which can delay resolution.


(2) The caller has no idea what will be shown to any given called party - depending on the destination CNAM service, it could be the correct name, nothing, just "Florida", or maybe the name of the person who had the same number six months ago and hopefully didn't sell adult entertainment.

[tmd] I agree that the caller generally cannot know what will be shown to any given called party.  I don't agree that this is always a function of the _destination_ CNAM service, though.  In "conventional" CNAM services (ref: GR-1188) the terminating exchange does a TCAP query to obtain calling name information from the originating network.  The result is in that case dictated by the caller's service provider, since it is they (or a 3rd party to whom they subcontract this service) who reply to the query.


(3) For some numbers, bad actors can insert any random information they choose, again with problem #1.

Even unsigned SIP display or Call-Info information, with some modicum of common behavior among carriers, will address all three problems, even if not perfectly, then most of the time. I may have no idea what validation Verizon uses to assure that their customers are indeed John Smith, but at least I know that I can tell who created the entry. A lawyer will know where to address the cease&desist letter if needed.

[tmd] That would be a clever lawyer.  As noted above, when incorrect calling name information is being displayed, it can be difficult to determine why.  I wish it were as simple as "if the caller is a Verizon customer, it must be Verizon's fault".  But it isn't.  Consider customers A and B.  A is a Verizon customer.  B is a CarrierB customer.  CarrierB uses 3rdPartyCnamLike service to obtain calling name information for incoming calls.  When A calls B, the name displayed to B doesn't come from Verizon.