Re: [stir] [sipcore] Adding categories from sipcore-callinfo-spam to draft-ietf-sipcore-callinfo-rcd-04

Samir Srivastava <srivastava_samir@hush.com> Mon, 21 March 2022 16:35 UTC

Return-Path: <srivastava_samir@hush.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EBD3A19FE for <stir@ietfa.amsl.com>; Mon, 21 Mar 2022 09:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.607
X-Spam-Level:
X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.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 aYYCOxX89TBG for <stir@ietfa.amsl.com>; Mon, 21 Mar 2022 09:35:31 -0700 (PDT)
Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B593A1A0D for <stir@ietf.org>; Mon, 21 Mar 2022 09:35:31 -0700 (PDT)
Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id C341A1813174 for <stir@ietf.org>; Mon, 21 Mar 2022 16:35:29 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=AoQuo5VFo2GPnT6YMH5lD5H4Sf6rqSs5IAYNgdAdVxA=; b=cxTiqUT41nlz4sx6FE2pVfUiW5X6HfbhQoMDvmd0bSHkZcC6lDQ+RRTdaujVT9AcdaVu22UJKBQmlOFgY7HzxotE31sP+qXLy1zKC1VllrtjSff1rQH2hvHTaUVs6o52iAWyQOd3gGWCeSbCqTr+BQ9R9ouYFBGzUTCneyygfZOSWVuGPq1OXg0y0r7ELCs4VekiPuD9ngXo0Lnku2098HdM48LcQGj9Nrck15Y0QQSM1GzVA1bjsmG84/VePLG9AcHRjCddmMTiBsYZDe4vFvNu4Ri/tRV4E/GwoNyuAhMwhAuqDmFDqYWUcOxktyDnhFf0bRG8DC6n0gtd4/+GCQ==
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Mon, 21 Mar 2022 16:35:29 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 48) id 3D5CA804471; Mon, 21 Mar 2022 16:35:29 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 21 Mar 2022 22:35:29 +0600
To: Pierce Gorman <pierce.gorman@t-mobile.com>, Henning Schulzrinne <hgs@cs.columbia.edu>, David Holmes <david.holmes@t-mobile.com>
Cc: stir@ietf.org, SIPCORE <sipcore@ietf.org>
From: Samir Srivastava <srivastava_samir@hush.com>
In-Reply-To: <BYAPR02MB4168F1B5E0E261CC51C36170D2159@BYAPR02MB4168.namprd02.prod.outlook.com>
References: <CACgrgBa-7pxgHygj+-bcE36AT3REBO1VDVRpyvj+auLnHN4+ug@mail.gmail.com> <MWHPR02MB287805ED59554A1C8FF99761AC0D9@MWHPR02MB2878.namprd02.prod.outlook.com> <CACgrgBYgmg1_auAkUOCuf07BF=CT_LVMpYA4-7eXSUwK0GM3og@mail.gmail.com> <20220316133923.351BE80E2C5@smtp.hushmail.com> <BYAPR02MB41685C1A98AB3F3CC322000DD2129@BYAPR02MB4168.namprd02.prod.outlook.com> <20220319213539.2174080E2C2@smtp.hushmail.com> <BYAPR02MB4168F1B5E0E261CC51C36170D2159@BYAPR02MB4168.namprd02.prod.outlook.com>
Content-Type: multipart/alternative; boundary="=_6ca90635f9592e0b3395edd1fda6731a"
Message-Id: <20220321163529.3D5CA804471@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/CrMV6aqBsyDsmXlST8vVEj94MC0>
Subject: Re: [stir] [sipcore] Adding categories from sipcore-callinfo-spam to draft-ietf-sipcore-callinfo-rcd-04
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 16:35:36 -0000

Hi Pierce,
  Thanks for your comments and going through the proposal.
   Are you in the agreement of solution to the problem?  
   Group members, please voice your opinion. 
ThanksSamir   
On 3/21/2022 at 4:02 AM, "Pierce Gorman"  wrote:      

	Thank you for the response Samir.  That helps me to understand.  I
think I understand at a very high level what you are advocating.  I
won’t argue the efficacy  of the approach but of course it may be
difficult to get agreement.  I don’t have any other comments or
flames at this time.  Thank you again. 
	Best regards, 
	Pierce Gorman
	From: Samir Srivastava  
 Sent: Saturday, March 19, 2022 4:36 PM
 To: Gorman, Pierce ; Henning Schulzrinne ; Holmes, David 
 Cc: stir@ietf.org; SIPCORE 
 Subject: Re: [sipcore] [stir] Adding categories from
sipcore-callinfo-spam to draft-ietf-sipcore-callinfo-rcd-04   
	[External]  
	 Hi Pierce, 

	 Thanx for spending time in reviewing.   

	 Robocall-Strike-Force-Final-Report mentions that robocall blocking
needs to be constantly evolving and adapting i.e. We will be always in
N+1 cycle.Whatever we develop today, robo-callers  (spammers) will
find another way for them. 

	 We can avoid  N+1 cycle, if we hit the problem at the motivation
level. 

	 In Complete Cashless Economy (CCE) i.e. When dollar is digital, we
will have end-to-end traceability of earning and spending of the
parties, as they are only dealt in computing devices.  There is no
hard currency equivalent. We cannot trace hard currency. Spammers make
the calls as they earn money from this.  This is the motivation for
them. Spammers cannot lie about the volume of the calls generated by
them. We need co-relation of earnings  and call volume (of spammers)
which is achievable in CCE.  

	 Here we are hitting the problem at the motivation level.  

	 In CCE, we will be having the system for catching other malpractices
(such as tracing funding of terrorism, bribery etc). For catching our
issue, we need additional co-relation system  with call volume. 

	 Complete Multimedia Recording (CMR) is one step further. We will be
always in multimedia recordings. Recordings will be viewed by law
enforcement when there is proper court subpoena  etc. In all
unfair/illegal actions, first privacy is misused then witnesses and
evidences are looked. Influential persons (backed by army of lawyers
to find the holes in the laws) with manipulation of evidence and
witnesses goes scott free. There are possible  unfair scenarios in CCE
also, such as misuse of technology, law, identity, leakage using word
of mouth etc. Due to misuse of these, loss of victim becomes gain of
gang of cheaters in CCE. CMR catches these also.  

	 We have been fixing the systems for impurity in humans. With CCE and
CMR, we are avoiding impurity in humans. When people will know that
they cannot misuse privacy, then they will  not commit unfair/illegal
action itself.  

	 Please refer  http://samirsrivastava.typepad.com  . It has slides
and papers on CCE and CMR . IT LISTS THE REASON FOR PEOPLE TO VOTE FOR
THESE CHANGES ALSO. 

	 CBDC is getting adopted by governments. If CMR gets the okay
(peer-reviewed) from IETF’ers, then it will be easy to convince the
governments for CMR. 

	 Your comments / flames are welcome. 

	 Thanks 

	 Samir 
 On 3/17/2022 at 8:10 PM, "Pierce Gorman"  wrote:      

	 Samir, 
	 Can you help us out a little?  I’m not following the connection
you’re trying to make between central bank cryptocurrencies and
combatting illegal robocalling using  SIP Identity headers. 
	 Pierce 
	 From: Samir Srivastava  
 Sent: Wednesday, March 16, 2022 8:39 AM
 To: Henning Schulzrinne ; Holmes, David 
 Cc: stir@ietf.org; SIPCORE 
 Subject: Re: [stir] [sipcore] Adding categories from
sipcore-callinfo-spam to draft-ietf-sipcore-callinfo-rcd-04  
	 Hi,  
	   Please analyze the SPAM in Complete Cashless Economy and Complete
Multimedia Recording environment. When there is end-to-end
traceability, we can know the source of income of Spammers.  Spammers
can not lie about the volume. This co-relation can force the penalties
for spammers and spam call volume will be reduced drastically.   
	   Apart from SPAM, these fixes other malpractices also.   
	   Refer the work at  https://samirsrivastava.typepad.com .   
	 Thanks   

	 Samir    
 On 3/13/2022 at 2:15 AM, "Henning Schulzrinne"  wrote:    

	 The basic idea originated in the FCC robocall strike force a few
years ago, with lots of carrier participation, so you could go back to
the various FCC reports that were produced  at the time for the
motivation and background (e.g.,
https://transition.fcc.gov/cgb/Robocall-Strike-Force-Final-Report.pdf 
and  https://www.fcc.gov/file/12311/download). This I-D and
requirements have been discussed since 2017, so this is hardly a new
idea. The draft itself has been through IESG review - I just never got
around to implement the changes requested.   
	 The basic requirement is that we want the receiving callee to make
automated or semi-automated judgements. Currently, the RCD draft has a
free-form field, but that doesn't really  help for anything automated
(or, say, displaying icons or other graphical elements).   
	 Like all spam labeling, this is probabilistic, i.e.,  if you're
waiting for perfection, this isn't for you. Current robocall filtering
services already label numbers with categories  (they are in the same
ballpark, but not exactly the same and each seems to differ a bit).
There are at least two possible sources:   
	 * For some labels, the calling party (with signing) will insert the
information, presumably for the more "positive" labels like "health"
or "government" or "personal". If a carrier  lies, this becomes either
a reputational issue ("never trust labels from carrier X") or
enforcement matter (e.g., as a potential deficiency in robocall
mitigation). The label may be part of the KYC process when a carrier
signs up a customer - after all, in  almost all cases this is pretty
obvious ("your business says Joe's Travel Agency. You are picking the
healthcare designation how?") A terminating carrier may, for example,
decide to only trust known carriers (say, T-Mobile) in deciding
whether to convey this  information to the called party.   
	 * An intermediary service used by the terminating carrier labels
(signed) numbers based on honeypots, crowdsourcing or number
databases, probably more focused on negative labels  like
"telemarketing" or "fraud". Again, versions of this exist today.   
	 Henning   
	 On Sat, Mar 12, 2022 at 3:10 PM Holmes, David  wrote:     

	 Hi Henning,    
	 Interesting idea, but who could define the categories, and who would
verify the claims?    
	 There may be something here, but this is a good example of where we
should agree the use cases and then define requirements before leaping
to solutions.    
	 BR/David Holmes/T-Mobile USA   
	 Get  Outlook for Android    
-------------------------
	 From: stir   on behalf of Henning Schulzrinne 
 Sent: Saturday, March 12, 2022 9:24:47 AM
 To: stir@ietf.org ; SIPCORE 
 Subject: [stir] Adding categories from sipcore-callinfo-spam to
draft-ietf-sipcore-callinfo-rcd-04   
	 [External]  
	 In trying to get back to looking at my ancient, dusty draft, a
thought: I think RCD would be significantly more useful if it
contained standardized categories of callers, such as  the one
included in callinfo-spam. This allows much better user interfaces and
automated handling ("send all political calls to voicemail", "play
special ringtone for personal calls").     
	 Henning