RE: [spitstop] [Sipping] RE: leaving it to the user (topic; SPIT)

"Saverio Niccolini" <Saverio.Niccolini@netlab.nec.de> Tue, 26 June 2007 11:27 UTC

Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39CW-0001HM-4p; Tue, 26 Jun 2007 07:27:16 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1I39CU-0001HH-TC for sipping-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 07:27:14 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39CU-0001H9-H2 for sipping@ietf.org; Tue, 26 Jun 2007 07:27:14 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I39CT-00046a-QP for sipping@ietf.org; Tue, 26 Jun 2007 07:27:14 -0400
Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0F07B200F030; Tue, 26 Jun 2007 13:27:05 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29RGFqRKGpIJ; Tue, 26 Jun 2007 13:27:04 +0200 (CEST)
Received: by smtp0.netlab.nec.de (Postfix, from userid 1001) id E383720102CD; Tue, 26 Jun 2007 13:27:04 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on atlas1.office
X-Spam-Level:
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7
Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 76C67200F030; Tue, 26 Jun 2007 13:26:48 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [spitstop] [Sipping] RE: leaving it to the user (topic; SPIT)
Date: Tue, 26 Jun 2007 13:27:50 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6960150ECAE@mx1.office>
In-Reply-To: <467D4AA7.2030502@gmx.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [spitstop] [Sipping] RE: leaving it to the user (topic; SPIT)
Thread-Index: Ace1tAZuDdIxpAVHTUm5bI2/LtxHVgCMDsQg
References: <0D22E3C1A7D7A843B12BF8C6F0A4075802149661@MCHP7IDA.ww002.siemens.net> <F640B5F5BA19954DB4812EB39575BB0E020915F2@MCHP7I5A.ww002.siemens.net><113091BD57179D4491C19DA7E10CD6960150E431@mx1.office> <467D4AA7.2030502@gmx.net>
From: Saverio Niccolini <Saverio.Niccolini@netlab.nec.de>
To: Signaling TO Prevent SPIT <spitstop@listserv.netlab.nec.de>
X-Sanitizer: This message has been sanitized!
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4
Cc: SIPPING LIST <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org

Hi all,
  
> * leave it to the user whether he wants to get something 
> filtered or treated differently, but

I think we all agree on this point and this is also what makes the
solution legally-compliant:
the user is anyway in control and the operator/provider just offer
a set of functionality to the user, either the users wants to
use themor it leaves to the operator/provider to make decision
on his/her behalf, but an agreement has to be in place

> * you might want to make information available to the VoIP 
> providers network to allow some of these statistical methods 
> to produce intelligent decisions and you might want to 
> execute the enforcement at the VoIP provider rather than at 
> the end host.

this is a completely different point, and I think info exchange
between provider is important. As Hannes said maybe not so important
to be standardized first, anyway this info exchange is exactly what is
detailed in our "scenarios" draft (see interface 'b'):
http://tools.ietf.org/id/draft-niccolini-sipping-spitstop-00.txt

Cheers,
Saverio

> 
> Ciao
> Hannes
> 
> 
> Saverio Niccolini wrote:
> > Dear Joachim,
> >
> > I agree with the argument to see many calls in order to decide.
> >
> > Anyway, legally speaking there is also the opposite 
> argument why you 
> > should actually leave it to the user:
> > -- if you suppress communications before they reach the end 
> user you 
> > may have legal troubles (at least in Germany I know about 
> this kind of 
> > law on suppression of communication), the user needs to 
> give explicit 
> > consent to suppress communications on his behalf.
> >
> > Thus, the evaluation is indeed to be done in the network while the 
> > final decision has to be on the user if he did not agree to 
> have the 
> > communication directed to him suppressed by the operator.
> >
> > Note that the user can also configure the terminal to suppress 
> > communication without the phone to ring (if the sapm level 
> estimated 
> > by your operator is too high for you to accept the call).
> >
> > For this and similar topics we have been working on the draft about 
> > signaling interfaces (to share the estimation done in the 
> network with 
> > the terminal, like X-spam level in email spam), see:
> > http://tools.ietf.org/id/draft-niccolini-sipping-spitstop-00.txt
> >
> > Cheers,
> > Saverio
> >
> > ============================================================
> > Dr. Saverio Niccolini
> > Senior Research Staff Member
> > Network Laboratories, NEC Europe Ltd.
> > Kurfuerstenanlage 36, D-69115 Heidelberg
> > Tel.     +49 (0)6221 4342-118
> > Fax:     +49 (0)6221 4342-155
> > e-mail:  saverio.niccolini@netlab.nec.de 
> > ============================================================
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >  
> > -----Original Message-----
> > From: Charzinski, Joachim [mailto:joachim.charzinski@nsn.com]
> > Sent: Monday, June 18, 2007 10:16 AM
> > To: Tschofenig, Hannes; SIPPING LIST
> > Cc: spitstop@listserv.netlab.nec.de
> > Subject: [Sipping] RE: leaving it to the user (topic; SPIT)
> >
> > there are two more arguments for not "leaving it to the user":
> >
> > 1. legal: In current telephone regulation, callers have a 
> >    right to have their ID hidden from the callee. 
> >    Current implementations transport the ID up to the last 
> >    (soft) switch etc and then anonymize the caller. That is, 
> >    a function in the network can but an end user device cannot 
> >    include caller ID (and what else do you really have in the 
> >    INVITE message) in evaluating spit probabilities. 
> > 2. statistical: A function in the network sees many more calls -  
> >    also by the same caller - than a function in an end user 
> >    device. For statistical evaluations, you need a LOT of calls 
> >    as a basis. 
> >
> > Best regards
> >
> > 	Joachim.
> >
> >   
> >> -----Original Message-----
> >> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]
> >> Sent: Monday, June 18, 2007 9:27 AM
> >> To: SIPPING LIST
> >> Subject: [Sipping] WG: leaving it to the user (topic; SPIT)
> >>
> >> Here is a forward of a review sent to us. 
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Albert Caruana
> >> Gesendet: Freitag, 15. Juni 2007 17:33
> >> An: Tschofenig, Hannes; hgs+ecrit@cs.columbia.edu; 
> dwing@cisco.com; 
> >> jdrosen@cisco.com; david.schwartz@kayote.com
> >> Cc: internet-drafts@ietf.org
> >> Betreff: leaving it to the user
> >>
> >> Hi
> >>
> >> I am very interested in security issues of emerging technologies.
> >>
> >> This is my personal opinion.
> >>
> >> I am both very pleased and somewhat dismayed reading the 
> draft IETF 
> >> document.
> >>
> >> The framweork proposed is great. The current statements to at best 
> >> help the user to make the decision as to what to refuse as 
> SPIT and 
> >> what to accept I find are decisions being taken without 
> considering 
> >> the user. Your mileage may vary.
> >> One phrase which i find smacks of choosing the path of least 
> >> resistance is:
> >> "For example, it is mandatory to pass full control of SPIT 
> filtering 
> >> to the end user, as this minimises legal problems".
> >>
> >> The legalproblems may need to be ironed out in other e.g. ITU and 
> >> ETSI task forces but should not be a hindrance to creating 
> mechanisms 
> >> properly preventing criminal abuse of computer systems such as the 
> >> acts of generating spit and spam.
> >>
> >> Users i know are furious over the need to set up spam 
> filters e.g. in 
> >> outlook client when e.g. gmail shows it can be done at incoming 
> >> server level.
> >> Even better would be egress capture of spam at the source 
> instead of 
> >> at the target server, relieving the internet of spam load 
> before it 
> >> happens.
> >>
> >> In my opinion, while a voip phone looks like a phone, the user is 
> >> usually not in a position to understand the legal or technical 
> >> differences between voip and PSTN/POTS technology.
> >>
> >> Leaving decisions up to the user is like assigning the 
> responsibility 
> >> for correct functioning of the suspension, braking and 
> fuel injection 
> >> system of a car to the driver instead of to the engineer 
> tuning the 
> >> car.
> >> I do not know whether you could drive one of the first automobiles 
> >> where the driver had to adjust the timing so that the engine would 
> >> run smoothly at start, later when running - and 
> differently for slow 
> >> revs and for high revs... Even Formula 1 drivers are backed by a 
> >> whole team of engineers and radio-diagnosis and control tools in 
> >> order to do such work on the fly.
> >>
> >> I would thus like to recommend that you incorporate such 
> preventive 
> >> medicinal thinking into the excellent framework being proposed and 
> >> which you have submitted, with a view to relieving the 
> >> ever-increasing numbers of non-technical users of voip  from the 
> >> responsibility of deciding what is the correct level of spit 
> >> filtering they should tolerate - and with the aim of 
> preventing spit 
> >> at source and ensuring audit trails are created which enable the 
> >> perpetrators to be located and punished under no matter 
> what legal system is in place anywhere.
> >>
> >> regards
> >> Albert Caruana
> >>
> >>
> >> _______________________________________________
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> sip-implementors@cs.columbia.edu for questions on current sip Use 
> >> sip@ietf.org for new developments of core SIP
> >>
> >>     
> > ----------------------------------------------------------
> > Nokia Siemens Networks
> > Joachim Charzinski
> > Principal Innovator
> > Machtlfinger Str. 1
> > D-81379 Muenchen
> > Germany
> > Tel: +49 89 722 46803
> > Joachim.Charzinski@nsn.com
> > http://www.nokiasiemensnetworks.com/global/
> >
> > Think before you print
> >
> > Nokia Siemens Networks GmbH & Co. KG - Sitz der 
> Gesellschaft: München 
> > / Registered office: Munich - Registergericht: München / Commercial 
> > registry: Munich, HRA 88537 - WEEE-Reg.-Nr.: DE 52984304 - 
> Persönlich 
> > haftende Gesellschafterin / General Partner: Nokia Siemens Networks 
> > Management GmbH - Geschäftsleitung / Board of Directors: Joachim 
> > Malterer, Lydia Sommer - Sitz der Gesellschaft: München / 
> Registered 
> > office: Munich - Registergericht: München / Commercial registry: 
> > Munich, HRB 163416
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > sip@ietf.org for new developments of core SIP 
> > _______________________________________________
> > spitstop mailing list
> > spitstop@listserv.netlab.nec.de
> > https://listserv.netlab.nec.de/mailman/listinfo/spitstop
> >   
> 
> _______________________________________________
> spitstop mailing list
> spitstop@listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
> 

============================================================
Dr. Saverio Niccolini
Senior Research Staff Member
Network Laboratories, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  saverio.niccolini@netlab.nec.de
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014
 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP