Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

"Asveren, Tolga" <tasveren@sonusnet.com> Wed, 19 July 2017 18:46 UTC

Return-Path: <tasveren@sonusnet.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE261267BB for <sipcore@ietfa.amsl.com>; Wed, 19 Jul 2017 11:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level:
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com
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 84aGe_1q5HVz for <sipcore@ietfa.amsl.com>; Wed, 19 Jul 2017 11:46:07 -0700 (PDT)
Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BBF12711E for <sipcore@ietf.org>; Wed, 19 Jul 2017 11:46:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cz2BFuh3IP/KTULufRwzwIquwndCBdmR2qX9MjhzEtU=; b=ZpjK9LJ0xJGuiKfqSvqyYLST3pUXTUypiuAHNWePhp6szB9KDiMLvnq3lWa6yY8S8JZzcdoH/Rr985KU3GEIQ88eCZoIVjvPZJQ7QM27+iF/l5V9q+sm9xPjQHp3xzwZ/HFKTzsjeqNJm8pM+9RJT5TwHLYIQsPw316haWZjOUo=
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-147-ul2bWlDpOFCutQsz5FiNYQ-1; Wed, 19 Jul 2017 14:46:04 -0400
Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2318.namprd03.prod.outlook.com (10.166.210.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Wed, 19 Jul 2017 18:46:02 +0000
Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1282.011; Wed, 19 Jul 2017 18:46:02 +0000
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
Thread-Index: AQHS//8f86lEHhh9VUKR5rSbwxo4z6Ja0ofAgABzoYCAAC1loIAAAo2AgAAGWUA=
Date: Wed, 19 Jul 2017 18:46:02 +0000
Message-ID: <SN2PR03MB2350B8FDFC86CC4DDA03F013B2A60@SN2PR03MB2350.namprd03.prod.outlook.com>
References: <CY1PR09MB07602078727954F586DCBDD3EAA10@CY1PR09MB0760.namprd09.prod.outlook.com> <SN2PR03MB235023C01D8658B9B25A3577B2A60@SN2PR03MB2350.namprd03.prod.outlook.com> <75f4364f-a10d-18eb-f547-8bdb17acef78@alum.mit.edu> <SN2PR03MB23509530AE70988D06A97191B2A60@SN2PR03MB2350.namprd03.prod.outlook.com> <CY1PR09MB07606A3F6AD98F8CB7235FD5EAA60@CY1PR09MB0760.namprd09.prod.outlook.com>
In-Reply-To: <CY1PR09MB07606A3F6AD98F8CB7235FD5EAA60@CY1PR09MB0760.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [73.29.18.75]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN2PR03MB2318; 20:smJARjdyBWq9Gi4TXU4Ss96iZCBYAAmZCwOHGOaAAMwJ8kEPaA14ODXacClyIsmIss25TPta+V0ZF7kfOAVBY5M9XUs+bp7+QqORTxrEaiOjYWK5lRBxYc4I61xtcE60XiDa6p9LBAehouiAMb+7SVbbZAMut0Sa1wEtbIEUeWk=
x-ms-office365-filtering-correlation-id: 00f367b4-87da-45a8-61c6-08d4ced667d0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN2PR03MB2318;
x-ms-traffictypediagnostic: SN2PR03MB2318:
x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(247924648384137);
x-microsoft-antispam-prvs: <SN2PR03MB2318967717B4E136FC759D16B2A60@SN2PR03MB2318.namprd03.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(2017060910075)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR03MB2318; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR03MB2318;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39400400002)(39410400002)(39450400003)(13464003)(377454003)(2501003)(3660700001)(230783001)(3280700002)(6506006)(77096006)(2950100002)(93886004)(33656002)(2171002)(53936002)(189998001)(6246003)(38730400002)(99286003)(3846002)(102836003)(55016002)(6116002)(9686003)(81166006)(8936002)(76176999)(50986999)(8676002)(7696004)(25786009)(5660300001)(6436002)(53546010)(86362001)(54356999)(2906002)(478600001)(229853002)(7736002)(305945005)(74316002)(14454004)(2900100001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2318; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: sonusnet.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2017 18:46:02.3493 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2318
X-MC-Unique: ul2bWlDpOFCutQsz5FiNYQ-1
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/c_EHawyHP-UAiiUt79ICvCvKDsg>
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 18:46:12 -0000

Agreed that this is somewhat about "philosophical aspects of priority". Having said that, I really feel not content with a fine-granularity indicator considering how in practice it would/could be generated especially considering all the operator/equipment/call scenario/deployment model combinations. It would be like, actually worse, than how sausages are prepared.

I am not religiously advocating a change toward a binary indicator (i.e. I wouldn't consider the current model as something "wrong") but IMHO that would be a more practical way of getting something useful at the end; just my 2 cents.

Thanks,
Tolga

-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] 
Sent: Wednesday, July 19, 2017 2:33 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
Subject: RE: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

This type of labeling is very common for email spam filters. It's essentially the same as "There's a 47% chance of rain today." Except that meteorologists are smart enough not to say 47%, but rather 50%.

It is better than the "According to the polls, candidate H has an 89% chance of winning the election." (Any semblance of initials to real persons has a 1-in-26 chance of being made up.)

Theoretically, unlike for elections and somewhat similar to the weather case, this is testable: You could take all the 50% spam or rain predictions, check with some reliable metric (human or rain gauge) whether the spam or rain happened and compare your results, i.e., roughly one in two such predictions should indeed turn out to be spam or rain. (It's more complicated than that, but we're getting pretty close to the philosophical debate of what probabilities mean when making predictions, which is apparently a rather unsettled scientific question.)

To actually answer your question: I don't think this is useful except as a rough way for users to trade false-positive/false-negative penalties. For example, they may discard all 80%+ probability calls, route 30-80% calls to voicemail and ring the below-30% calls. The thresholds are arbitrary, but users may tune them based on experience ("all the calls in voicemail were spam, so I can go lower").

Some people pack an umbrella when there's a 20% chance of rain, others are more willing to risk getting wet. By the way, it is well-known that meteorologists over-predict rain since nobody complains if they did not get soaked.

Henning

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga
Sent: Wednesday, July 19, 2017 2:11 PM
To: Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-spam-01 - SIP entities

Let me ask this question then:
What would "spam with a likelihood of 47%" mean? Will the specification detail how this percentage need to be calculated? Otherwise how can the end-device take some action based on this value? One could argue that all these are "implementation dependent" but honestly I think this would just create confusion/chaos in practice and likely to be not useful.

Thanks,
Tolga