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

"Saverio Niccolini" <Saverio.Niccolini@netlab.nec.de> Tue, 19 June 2007 10:31 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 1I0azg-00037m-ID; Tue, 19 Jun 2007 06:31:28 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1I0aze-00037f-E9 for sipping-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 06:31:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aze-00037A-4H for sipping@ietf.org; Tue, 19 Jun 2007 06:31:26 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0azb-0006fP-C3 for sipping@ietf.org; Tue, 19 Jun 2007 06:31:26 -0400
Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AD35A200017E; Tue, 19 Jun 2007 12:31:22 +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 OQYPhQeQByi8; Tue, 19 Jun 2007 12:31:22 +0200 (CEST)
Received: by smtp0.netlab.nec.de (Postfix, from userid 1001) id 8EA96200CAB5; Tue, 19 Jun 2007 12:31:22 +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 6CBEB200017E; Tue, 19 Jun 2007 12:31:01 +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: [Sipping] RE: leaving it to the user (topic; SPIT)
Date: Tue, 19 Jun 2007 12:31:48 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6960150E431@mx1.office>
In-Reply-To: <F640B5F5BA19954DB4812EB39575BB0E020915F2@MCHP7I5A.ww002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] RE: leaving it to the user (topic; SPIT)
Thread-Index: AcevYomhL9SxoPCvRM2zIrP+XvqT5wCF2BpgAAFQbTAANqMeoA==
References: <0D22E3C1A7D7A843B12BF8C6F0A4075802149661@MCHP7IDA.ww002.siemens.net> <F640B5F5BA19954DB4812EB39575BB0E020915F2@MCHP7I5A.ww002.siemens.net>
From: Saverio Niccolini <Saverio.Niccolini@netlab.nec.de>
To: "Charzinski, Joachim" <joachim.charzinski@nsn.com>, "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>, SIPPING LIST <sipping@ietf.org>
X-Sanitizer: This message has been sanitized!
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Cc: spitstop@listserv.netlab.nec.de
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

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


_______________________________________________
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