From rucus-bounces@ietf.org Fri May 2 10:55:31 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A176B3A68B8; Fri, 2 May 2008 10:55:31 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6C328C19E for ; Fri, 2 May 2008 10:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOcTDar6vtsw for ; Fri, 2 May 2008 10:55:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4BA0228C44A for ; Fri, 2 May 2008 10:54:58 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 02 May 2008 10:55:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m42HsxBl025993 for ; Fri, 2 May 2008 10:54:59 -0700 Received: from dwingwxp01 ([10.32.240.195]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m42Hsxnb002493 for ; Fri, 2 May 2008 17:54:59 GMT From: "Dan Wing" To: Date: Fri, 2 May 2008 10:54:57 -0700 Message-ID: <01d701c8ac7d$a3843860$c3f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcisfaJaC0WUFAhDTpC6QNaeYa1Osg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=277; t=1209750899; x=1210614899; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20audio=20turing=20test |Sender:=20; bh=LtVaVwiFOy5fI2ERZbqFB70GwDWQZg0lY32yoFKIxzk=; b=QtCmjvS+iivjdWwebFfTg1vFd9Gh6h4/+ZjwNvrbgpIYmx+QfSd/5FRWay 6pMWUbEVF40Kh8DFbCkp3Y22mkDk6hoJ64BethsaL9pziBYdYWEcva+kQlhj qtimuGK7Ln; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Rucus] audio turing test X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org An audio Turing test ("Press 53#2 to continue") falls. Towards the end, the author points out that Facebook's audio Turing test also has some weaknesses. -d _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 2 13:33:29 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE8E28C1CE; Fri, 2 May 2008 13:33:29 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1377B3A69BA; Fri, 2 May 2008 13:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+Ihfrm6-ppC; Fri, 2 May 2008 13:33:19 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 842143A67E5; Fri, 2 May 2008 13:33:19 -0700 (PDT) Received: from pc-00144.lodestar2.dyndns.org (account dyork [75.68.245.43] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 30517172; Fri, 02 May 2008 20:33:20 +0000 Message-Id: From: Dan York To: sipping List Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 2 May 2008 16:33:19 -0400 X-Mailer: Apple Mail (2.919.2) Cc: rucus BoF Subject: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org SIPPING & RUCUS, Because I've had some various pieces of feedback on the document, I'm going to rev draft-york-sipping-spit-similarity-scenarios in the next week or so to incorporate that feedback. Since I'm doing so, I thought I'd just ask.... anyone else have comments on: http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios-00.txt Additional scenarios you think I should include.... points of clarification... whatever? Thanks, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat May 3 09:40:33 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DA43A6DD5; Sat, 3 May 2008 09:40:33 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDAB28C2BC for ; Sat, 3 May 2008 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DceVk7sduXtY for ; Sat, 3 May 2008 09:40:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7E7A828C2D8 for ; Sat, 3 May 2008 09:39:24 -0700 (PDT) Received: (qmail invoked by alias); 03 May 2008 16:39:24 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp048) with SMTP; 03 May 2008 18:39:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18dT8UgS7sdf4Zpdy2lmjaJnphfLb6U7u+/mJVI92 +8aFUplq/zFAt+ Message-ID: <481C953A.5000704@gmx.net> Date: Sat, 03 May 2008 19:39:22 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan York References: In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Dan, I like your document, as mentioned previously already. I shows some of the limitations with systems that use learning of past behavior as their basis for future actions. Some of the statistical techniques belong to this category. However, the most important question is: What should happen with the document at the end? Furthermore, the document points to potential problems to a specific category of solutions. For systems that do not rely on learning techniques these scenarios are not a problem as such. Ciao Hannes Dan York wrote: > SIPPING & RUCUS, > > Because I've had some various pieces of feedback on the document, I'm > going to rev draft-york-sipping-spit-similarity-scenarios in the next > week or so to incorporate that feedback. Since I'm doing so, I > thought I'd just ask.... anyone else have comments on: > > http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios-00.txt > > Additional scenarios you think I should include.... points of > clarification... whatever? > > Thanks, > Dan > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat May 3 13:12:39 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E4E3A6ACC; Sat, 3 May 2008 13:12:39 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B2A3A6BEF for ; Sat, 3 May 2008 13:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Phf2CdgFj7 for ; Sat, 3 May 2008 13:12:37 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id 568A93A6ACC for ; Sat, 3 May 2008 13:12:37 -0700 (PDT) Received: from pc-00144.lodestar2.dyndns.org (account dyork [75.68.245.43] verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 30535674; Sat, 03 May 2008 20:12:37 +0000 Message-Id: <7E2D0B44-3DCA-4606-89D1-534D74B5328F@voxeo.com> From: Dan York To: Hannes Tschofenig In-Reply-To: <481C953A.5000704@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 3 May 2008 16:12:36 -0400 References: <481C953A.5000704@gmx.net> X-Mailer: Apple Mail (2.919.2) Cc: rucus BoF Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, > I like your document, as mentioned previously already. I shows some > of the limitations with systems that use learning of past behavior > as their basis for future actions. Some of the statistical > techniques belong to this category. DY> Yes, you have mentioned this before. Thank you. > However, the most important question is: What should happen with the > document at the end? DY> Good question. My goal with the document was really to inform the ongoing debate and ensure that these points were being considered. There's probably a couple of tracks the document could take: 1. Do nothing further with it beyond the next revision. The point has been made. It can continue to exist as a current (and then expired) Internet-Draft. 2. Fold it into some larger problem statement document along with similar views for other categories of solutions. Or do something else entirely... I don't actually know. > > Furthermore, the document points to potential problems to a specific > category of solutions. For systems that do not rely on learning > techniques these scenarios are not a problem as such. DY> Yes. In fact, the majority of SPIT/SPAM solutions *suggested by the IETF* so far are NOT this category of solutions. Now, I can completely see the various network security vendors looking to try to address voice SPAM/SPIT using these techniques... but I have not really seen any of these solutions being brought into the IETF yet. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sun May 4 06:00:28 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C543A6DC4; Sun, 4 May 2008 06:00:28 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CDE3A6D86 for ; Sun, 4 May 2008 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlHu1+ANaqHV for ; Sun, 4 May 2008 06:00:10 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 2227E3A6DCE for ; Sun, 4 May 2008 06:00:09 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m44D04po011108; Sun, 4 May 2008 16:00:06 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 May 2008 16:00:04 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 May 2008 16:00:04 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 May 2008 16:00:03 +0300 Message-ID: In-Reply-To: <7E2D0B44-3DCA-4606-89D1-534D74B5328F@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Any further commentson draft-york-sipping-spit-similarity-scenarios-00.txt ? Thread-Index: AcitWhE5weD2PoT+QHyf19rQhs9yWgAi20LA References: <481C953A.5000704@gmx.net> <7E2D0B44-3DCA-4606-89D1-534D74B5328F@voxeo.com> From: To: , X-OriginalArrivalTime: 04 May 2008 13:00:04.0445 (UTC) FILETIME=[C54F48D0:01C8ADE6] X-Nokia-AV: Clean Cc: rucus@ietf.org Subject: Re: [Rucus] Any further commentson draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Dan, >Hannes, > >> I like your document, as mentioned previously already. I >shows some of >> the limitations with systems that use learning of past behavior as >> their basis for future actions. Some of the statistical techniques >> belong to this category. > >DY> Yes, you have mentioned this before. Thank you. > >> However, the most important question is: What should happen with the >> document at the end? > >DY> Good question. My goal with the document was really to inform the >ongoing debate and ensure that these points were being considered. >There's probably a couple of tracks the document could take: > >1. Do nothing further with it beyond the next revision. The >point has been made. It can continue to exist as a current >(and then expired) Internet-Draft. >2. Fold it into some larger problem statement document along >with similar views for other categories of solutions. I prefer (2) together with David's document. > >Or do something else entirely... I don't actually know. >> >> Furthermore, the document points to potential problems to a specific >> category of solutions. For systems that do not rely on learning >> techniques these scenarios are not a problem as such. > >DY> Yes. In fact, the majority of SPIT/SPAM solutions *suggested by >the IETF* so far are NOT this category of solutions. Now, I >can completely see the various network security vendors >looking to try to address voice SPAM/SPIT using these >techniques... but I have not really seen any of these >solutions being brought into the IETF yet. You are right. In some sense one could use your document as a requirements document in the style of: "Ah. You are developing a SPIT solution then please tell us how you address these scenarios." Ciao Hannes > >Regards, >Dan >-- >Dan York, CISSP, Director of Emerging Communication Technology >Office of the CTO Voxeo Corporation dyork@voxeo.com >Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > >Build voice applications based on open standards. >Find out how at http://www.voxeo.com/free > > > > > >_______________________________________________ >Rucus mailing list >Rucus@ietf.org >https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 5 11:39:23 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2C53A6952; Mon, 5 May 2008 11:39:23 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B10B3A6901 for ; Mon, 5 May 2008 11:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkDi5WW6G9hg for ; Mon, 5 May 2008 11:39:17 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4BF9E3A6985 for ; Mon, 5 May 2008 11:39:17 -0700 (PDT) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 907482C0012A7; Mon, 5 May 2008 20:38:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGdSQL1cKlFf; Mon, 5 May 2008 20:38:50 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 6FB6D2C0012A5; Mon, 5 May 2008 20:38:35 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 May 2008 20:38:59 +0200 Message-ID: <45EDF1C5D301ED41A339796A9F979F720FDA64@eris.office> In-Reply-To: <481C953A.5000704@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? Thread-Index: AcitPIBl4Oc+MeD3TBGG4EK9b5P8gABoV1kg References: <481C953A.5000704@gmx.net> From: "Saverio Niccolini" To: "Hannes Tschofenig" , "Dan York" Cc: rucus BoF Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear Hannes, > I like your document, as mentioned previously already. I > shows some of the limitations with systems that use learning > of past behavior as their basis for future actions. Some of > the statistical techniques belong to this category. we all agree statistical techniques do have limitations, but they are also powerful and this does not mean they should not be considered in the RUCUS work I remember all the list of methods indicated by Henning during the BOF as most promising (check his ppt slides): -- identity-based -- statistics -- price-based For some of the scenarios Dan describes in his draft the statistical techniques will never come into play: -- "emergency notifications": if you have strong identities in place and you are sure nobody can steal them, you just need to insert the URIs that are allowed to send "emergency notification" into the white list --> no need to apply statistics, just work on policy and identity-based mechanisms (statistics are useful here to check misbehaviours) -- Urgent Notification Systems: a bit more complicated but there is always a previous relationship between caller and callee, thus also here one could get around them without statistics but with policies and identity-based mechanisms -- for the other systems I would always repeat what I just wrote: apply policies and identity-based mechanisms The statistics are good when ther eis no previous relationship between the caller and the callee and this is why they are useful Thus if you want to choose the three class of mechanisms that RUCUS should suggest just choose these three.. Cheers, Saverio > However, the most important question is: What should happen > with the document at the end? > Furthermore, the document points to potential problems to a > specific category of solutions. For systems that do not rely > on learning techniques these scenarios are not a problem as such. > > Ciao > Hannes > > > > Dan York wrote: > > SIPPING & RUCUS, > > > > Because I've had some various pieces of feedback on the > document, I'm > > going to rev draft-york-sipping-spit-similarity-scenarios > in the next > > week or so to incorporate that feedback. Since I'm doing so, I > > thought I'd just ask.... anyone else have comments on: > > > > > > > http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios- > > 00.txt > > > > Additional scenarios you think I should include.... points of > > clarification... whatever? > > > > Thanks, > > Dan > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > ============================================================ Dr. Saverio Niccolini NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 5 11:43:26 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763553A69DF; Mon, 5 May 2008 11:43:26 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F843A69DF for ; Mon, 5 May 2008 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wja9lPjpBhFf for ; Mon, 5 May 2008 11:43:24 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 28B193A6935 for ; Mon, 5 May 2008 11:43:24 -0700 (PDT) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id AF4902C0012A7; Mon, 5 May 2008 20:42:57 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa6P9ScxfKf5; Mon, 5 May 2008 20:42:57 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 934372C0012A5; Mon, 5 May 2008 20:42:37 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 May 2008 20:43:01 +0200 Message-ID: <45EDF1C5D301ED41A339796A9F979F720FDA65@eris.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Any furthercommentson draft-york-sipping-spit-similarity-scenarios-00.txt ? Thread-Index: AcitWhE5weD2PoT+QHyf19rQhs9yWgAi20LAAD5z48A= References: <481C953A.5000704@gmx.net><7E2D0B44-3DCA-4606-89D1-534D74B5328F@voxeo.com> From: "Saverio Niccolini" To: , , Cc: rucus@ietf.org Subject: Re: [Rucus] Any furthercommentson draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear all, > >> However, the most important question is: What should > happen with the > >> document at the end? > > > >DY> Good question. My goal with the document was really to inform the > >ongoing debate and ensure that these points were being considered. > >There's probably a couple of tracks the document could take: > > > >1. Do nothing further with it beyond the next revision. The > point has > >been made. It can continue to exist as a current (and then expired) > >Internet-Draft. > >2. Fold it into some larger problem statement document along with > >similar views for other categories of solutions. > > I prefer (2) together with David's document. I support this option. > You are right. In some sense one could use your document as a > requirements document in the style of: "Ah. You are > developing a SPIT solution then please tell us how you > address these scenarios." right, if we develop any framework for preventing UC we should be surethat we do not block such communications --> that is why I think the policy draft of Hannes is an important piece of work (but only a part of it, not the whole picture) Saverio ============================================================ Dr. Saverio Niccolini NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu May 8 08:49:36 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7B128D13A; Thu, 8 May 2008 08:49:36 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9909928CE44 for ; Thu, 8 May 2008 08:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga22ucIGgOmg for ; Thu, 8 May 2008 08:49:32 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 30BA728D552 for ; Thu, 8 May 2008 07:08:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 9928F2C00C51F for ; Thu, 8 May 2008 10:32:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7KT4ClT+R0H for ; Thu, 8 May 2008 10:32:41 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 6ED402C0012A6 for ; Thu, 8 May 2008 10:32:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 8 May 2008 10:32:36 +0200 Message-ID: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: how to move forward towards an EG Thread-Index: Aciw5hF+ltUaqjZ1TtGCwlyDjxq+OQ== From: "Jan Seedorf" To: Subject: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear all, I would like to make a proposal on how to move forward with RUCUS (after all, it should be the discussion on this mailing list that drives RUCUS towards an EG). During the BoF in Philadelphia, Henning Schulzrinne presented some slides (see https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) which in my opinion include some key ideas for potential RUCUS work and goals on which I have not seen much discussion on this list (at least not directly): -- We should keep in mind that attacks and mechanisms (as countermeasures against unsolicited communications) are likely to evolve. Thus, RUCUS work should focus on a flexible "communication glue" for mechanisms to communicate in a (distributed) setting, or as Henning put it "separate mechanisms from communication protocols". In that sense, RUCUS as an EG could/should work out what communication protocol properties are necessary to achieve this flexible communication glue. Such communication glue should be independent of concrete mechanisms and allow for evolving mechanisms. -- There is a need for distributed communication among entities (e.g., configuring and communicating authorization policies, querying oracles, conveying downstream metrics, see the slides). This includes the need for a common policy language to enable the communication of authorization policies. This would allow for automated decisions, so that for instance based on a) some call characteristics perceived and b) a policy set by a user (where a) and b) are at different locations) actions on a SIP message can be taken (e.g., "forward to mailbox"). Therefore, such communication glue would need to allow for distributed communication and to allow mechanisms from different vendors to work together (something where the e-mail world has failed). At the BoF in Philly it was agreed to follow the proposal from Jonathan Rosenberg to select 3 mechanisms from the ones in RFC 5039 and explore these in detail. Following the points above (to make distinct that very concrete mechanisms should not be standardised because these would only be of limited value due to evolving attacks), I think RUCUS should consider 3 prototypical "classes" of mechanisms as key ones (e.g., identity-based mechanisms, statistics-based mechanisms, ... -> to be agreed on) and then work on how these could fit in an overall architecture and what "communication glue" between entities would be necessary for these "classes of mechanisms" to work interoperable in a distributed setting (I believe this lies in the spirit of the proposal by Jonathan when he talked about 3 mechanisms: to have RUCUS explore what general communication properties are necessary, but limiting the work to 3 classes of mechanisms in order to make the charter achievable in resonable time). I am interested to hear what others think about the slides Henning presented and the potential goals for RUCUS discussed above. Please provide comments so that we can find consensus and confine these ideas towards an updated charter for the RUCUS EG, convincing the ADs to grant it. Kind regards, Jan P.S.: Admitedly, some text parts above are taken directly from the slides Henning presented ============================================================ Jan Seedorf Research Scientist NEC Europe Ltd., NEC Laboratories Europe, Network Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221 Fax: +49 (0)6221 4342-155 e-mail: jan.seedorf@nw.neclab.eu ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 9 01:41:18 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660213A67B0; Fri, 9 May 2008 01:41:18 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EED13A67A9 for ; Fri, 9 May 2008 01:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUX2DhaO3Qde for ; Fri, 9 May 2008 01:41:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 800CF3A67B0 for ; Fri, 9 May 2008 01:40:30 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2008 08:17:56 -0000 Received: from dhcp-25-105.ripemtg.ripe.net (EHLO [193.0.25.105]) [193.0.25.105] by mail.gmx.net (mp048) with SMTP; 09 May 2008 10:17:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/GHmcTI3/GXijmxcOnnd2S9GvB0XgwNh9iQxH2v0 uPxPGT8HYb+tGv Message-ID: <482408B5.4050802@gmx.net> Date: Fri, 09 May 2008 11:17:57 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Saverio Niccolini References: <481C953A.5000704@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDA64@eris.office> In-Reply-To: <45EDF1C5D301ED41A339796A9F979F720FDA64@eris.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I agree with you, Saverio. Nevertheless it is a good idea to keep the scenarios Dan has described in his document in mind and to consider them in the overall solution. Saverio Niccolini wrote: > Dear Hannes, > > >> I like your document, as mentioned previously already. I >> shows some of the limitations with systems that use learning >> of past behavior as their basis for future actions. Some of >> the statistical techniques belong to this category. >> > > we all agree statistical techniques do have limitations, but > they are also powerful and this does not mean they should not > be considered in the RUCUS work > > I remember all the list of methods indicated by Henning during > the BOF as most promising (check his ppt slides): > -- identity-based > -- statistics > -- price-based > > For some of the scenarios Dan describes in his draft the statistical > techniques will never come into play: > -- "emergency notifications": if you have strong identities in place > and you are sure nobody can steal them, you just need to insert the > URIs that are allowed to send "emergency notification" into the > white list --> no need to apply statistics, just work on policy and > identity-based mechanisms (statistics are useful here to check misbehaviours) > > -- Urgent Notification Systems: a bit more complicated but there is always > a previous relationship between caller and callee, thus also here > one could get around them without statistics but with policies and identity-based > mechanisms > > -- for the other systems I would always repeat what I just wrote: > apply policies and identity-based mechanisms > > The statistics are good when ther eis no previous relationship between > the caller and the callee and this is why they are useful > > Thus if you want to choose the three class of mechanisms that RUCUS should > suggest just choose these three.. > > Cheers, > Saverio > > >> However, the most important question is: What should happen >> with the document at the end? >> Furthermore, the document points to potential problems to a >> specific category of solutions. For systems that do not rely >> on learning techniques these scenarios are not a problem as such. >> >> Ciao >> Hannes >> >> >> >> Dan York wrote: >> >>> SIPPING & RUCUS, >>> >>> Because I've had some various pieces of feedback on the >>> >> document, I'm >> >>> going to rev draft-york-sipping-spit-similarity-scenarios >>> >> in the next >> >>> week or so to incorporate that feedback. Since I'm doing so, I >>> thought I'd just ask.... anyone else have comments on: >>> >>> >>> >>> >> http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios- >> >>> 00.txt >>> >>> Additional scenarios you think I should include.... points of >>> clarification... whatever? >>> >>> Thanks, >>> Dan >>> >>> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> > > > ============================================================ > Dr. Saverio Niccolini > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 9 01:55:00 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F023A67B0; Fri, 9 May 2008 01:55:00 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34493A67B0 for ; Fri, 9 May 2008 01:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TIME=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg85l2it0zr0 for ; Fri, 9 May 2008 01:54:58 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 807D93A67A9 for ; Fri, 9 May 2008 01:54:57 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2008 08:32:13 -0000 Received: from dhcp-25-105.ripemtg.ripe.net (EHLO [193.0.25.105]) [193.0.25.105] by mail.gmx.net (mp007) with SMTP; 09 May 2008 10:32:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+zezAhEDmzg3iemD6AyPwMs3dtdjMWOzAGhiyrOP ENfDlaoogLHsHh Message-ID: <48240C0F.1080600@gmx.net> Date: Fri, 09 May 2008 11:32:15 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jan Seedorf References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> In-Reply-To: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Jan, at slide 12 of https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm Henning lists what the outcome of the work would be, namely: * mechanisms to convey metrics downstream * mechanisms to query oracles * policy languages to allow automated decisions Working on the specific solutions is not the job of an EG; this is the work that would be done afterwards in a working group. Hence, what we would want todo in an EG is to decide on the mechanisms one would pick (in Henning's case the above three). Other folks may have different mechanisms in mind. Jonathan proposed to again describe the mechanisms as an excercise to pick a certain number of mechanisms. For example, one would describe what white lists do, what features they provide, where they provide advantages and where they fail. I considered this as a useless excercise for 2 reasons: a) we already know the mechanisms. Their properties are already known and described. See for example RFC 5039 b) many mechanisms need to be used in concert with some other mechanisms (example: strong identities are nice but you need to make an authorization decision afterwards; white lists are useless if there is no strong identity mechanisms, etc. ) Hence, I suggested to write a framework that lists a few mechanism that make sense when used together. This means selecting useful building blocks. I believe we are able to write such a document in the timeframe of an EG. Then, we move on to the work on the detailed solutions. Ciao Hannes Jan Seedorf wrote: > Dear all, > > I would like to make a proposal on how to move forward with RUCUS (after all, it should be the discussion on this mailing list that drives RUCUS towards an EG). During the BoF in Philadelphia, Henning Schulzrinne presented some slides (see https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) which in my opinion include some key ideas for potential RUCUS work and goals on which I have not seen much discussion on this list (at least not directly): > > -- We should keep in mind that attacks and mechanisms (as countermeasures against unsolicited communications) are likely to evolve. Thus, RUCUS work should focus on a flexible "communication glue" for mechanisms to communicate in a (distributed) setting, or as Henning put it "separate mechanisms from communication protocols". In that sense, RUCUS as an EG could/should work out what communication protocol properties are necessary to achieve this flexible communication glue. Such communication glue should be independent of concrete mechanisms and allow for evolving mechanisms. > > -- There is a need for distributed communication among entities (e.g., configuring and communicating authorization policies, querying oracles, conveying downstream metrics, see the slides). This includes the need for a common policy language to enable the communication of authorization policies. This would allow for automated decisions, so that for instance based on a) some call characteristics perceived and b) a policy set by a user (where a) and b) are at different locations) actions on a SIP message can be taken (e.g., "forward to mailbox"). Therefore, such communication glue would need to allow for distributed communication and to allow mechanisms from different vendors to work together (something where the e-mail world has failed). > > At the BoF in Philly it was agreed to follow the proposal from Jonathan Rosenberg to select 3 mechanisms from the ones in RFC 5039 and explore these in detail. Following the points above (to make distinct that very concrete mechanisms should not be standardised because these would only be of limited value due to evolving attacks), I think RUCUS should consider 3 prototypical "classes" of mechanisms as key ones (e.g., identity-based mechanisms, statistics-based mechanisms, ... -> to be agreed on) and then work on how these could fit in an overall architecture and what "communication glue" between entities would be necessary for these "classes of mechanisms" to work interoperable in a distributed setting (I believe this lies in the spirit of the proposal by Jonathan when he talked about 3 mechanisms: to have RUCUS explore what general communication properties are necessary, but limiting the work to 3 classes of mechanisms in order to make the charter achievable in resonable tim > e). > > I am interested to hear what others think about the slides Henning presented and the potential goals for RUCUS discussed above. Please provide comments so that we can find consensus and confine these ideas towards an updated charter for the RUCUS EG, convincing the ADs to grant it. > > Kind regards, > Jan > > P.S.: Admitedly, some text parts above are taken directly from the slides Henning presented > > ============================================================ > Jan Seedorf > Research Scientist > NEC Europe Ltd., NEC Laboratories Europe, Network Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-221 > Fax: +49 (0)6221 4342-155 > e-mail: jan.seedorf@nw.neclab.eu > ============================================================ > NEC Europe Limited Registered Office: NEC House, > 1 Victoria Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 9 02:09:36 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C24F3A6837; Fri, 9 May 2008 02:09:36 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256953A6837 for ; Fri, 9 May 2008 02:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37ApHIURnSVw for ; Fri, 9 May 2008 02:09:33 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id A4C6A3A67A9 for ; Fri, 9 May 2008 02:09:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 07E3C2C0012A6; Fri, 9 May 2008 11:06:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFR+MleGVGAd; Fri, 9 May 2008 11:06:43 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 9F5D82C00C520; Fri, 9 May 2008 11:06:27 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 11:06:28 +0200 Message-ID: <45EDF1C5D301ED41A339796A9F979F720FDFC9@eris.office> In-Reply-To: <482408B5.4050802@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? Thread-Index: AcixrTZ6fB0VQCAbSZOuSmKCnoHzVwABKPMQ References: <481C953A.5000704@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDA64@eris.office> <482408B5.4050802@gmx.net> From: "Saverio Niccolini" To: "Hannes Tschofenig" Cc: rucus BoF Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, I am fine with keeping scenarios as Dan described to give people an idea of what they risk (kind of pitfalls) if they not look carefully into configuration of certain polcies. Actually this is part of what we think would be the direction of RUCUS: -- "reference scenario": let's take a reference scenario, e.g. a simple standard SIP one like slide 11 of Henning's presentation (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) and let's add what the pitfalls are (Dan's doc), add the considerations of David about the problem statement and the ones of Otmar which people seems to agree on -- "framework" or "communication glue" --> see Jan's email for this we see slide 11 of Henning's presentation (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) as the best example --> it includes polcies and signalling extensions to query oracles and allow distirbuted decisions --> it would not hint to specific solution mechanisms if well defined -- "class of mechanisms" -- see also Jan's email this is what Jonathan proposed at the BOF and people agreed on, actually we speak about classes since single mechanisms do not make entire sense at this point in time I do not seen any problem with this approach and I hope to see large consensus, I think this is clean and simple and we can achieve this in the 6 months of an EG. Can we agree on this, write the charter proposal around that, have ADs convinced and start real work? Comments? Saverio ============================================================ Dr. Saverio Niccolini NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, May 09, 2008 10:18 AM > To: Saverio Niccolini > Cc: Dan York; rucus BoF > Subject: Re: [Rucus] Any further comments on > draft-york-sipping-spit-similarity-scenarios-00.txt ? > > I agree with you, Saverio. Nevertheless it is a good idea to > keep the scenarios Dan has described in his document in mind > and to consider them in the overall solution. > > > Saverio Niccolini wrote: > > Dear Hannes, > > > > > >> I like your document, as mentioned previously already. I > shows some > >> of the limitations with systems that use learning of past > behavior as > >> their basis for future actions. Some of the statistical techniques > >> belong to this category. > >> > > > > we all agree statistical techniques do have limitations, > but they are > > also powerful and this does not mean they should not be > considered in > > the RUCUS work > > > > I remember all the list of methods indicated by Henning > during the BOF > > as most promising (check his ppt slides): > > -- identity-based > > -- statistics > > -- price-based > > > > For some of the scenarios Dan describes in his draft the > statistical > > techniques will never come into play: > > -- "emergency notifications": if you have strong identities > in place > > and you are sure nobody can steal them, you just need to insert the > > URIs that are allowed to send "emergency notification" into > the white > > list --> no need to apply statistics, just work on policy and > > identity-based mechanisms (statistics are useful here to check > > misbehaviours) > > > > -- Urgent Notification Systems: a bit more complicated but there is > > always a previous relationship between caller and callee, thus also > > here one could get around them without statistics but with policies > > and identity-based mechanisms > > > > -- for the other systems I would always repeat what I just wrote: > > apply policies and identity-based mechanisms > > > > The statistics are good when ther eis no previous > relationship between > > the caller and the callee and this is why they are useful > > > > Thus if you want to choose the three class of mechanisms that RUCUS > > should suggest just choose these three.. > > > > Cheers, > > Saverio > > > > > >> However, the most important question is: What should > happen with the > >> document at the end? > >> Furthermore, the document points to potential problems to > a specific > >> category of solutions. For systems that do not rely on learning > >> techniques these scenarios are not a problem as such. > >> > >> Ciao > >> Hannes > >> > >> > >> > >> Dan York wrote: > >> > >>> SIPPING & RUCUS, > >>> > >>> Because I've had some various pieces of feedback on the > >>> > >> document, I'm > >> > >>> going to rev draft-york-sipping-spit-similarity-scenarios > >>> > >> in the next > >> > >>> week or so to incorporate that feedback. Since I'm doing so, I > >>> thought I'd just ask.... anyone else have comments on: > >>> > >>> > >>> > >>> > >> > http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios > >> - > >> > >>> 00.txt > >>> > >>> Additional scenarios you think I should include.... points of > >>> clarification... whatever? > >>> > >>> Thanks, > >>> Dan > >>> > >>> > >> _______________________________________________ > >> Rucus mailing list > >> Rucus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rucus > >> > >> > > > > > > ============================================================ > > Dr. Saverio Niccolini > > NEC Laboratories Europe, Network Research Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-118 > > Fax: +49 (0)6221 4342-155 > > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL Registered in England 2832014 > > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 9 02:30:43 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C583A683F; Fri, 9 May 2008 02:30:43 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D163A683F for ; Fri, 9 May 2008 02:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.189 X-Spam-Level: X-Spam-Status: No, score=-1.189 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, MANGLED_TIME=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWQq96hB69uW for ; Fri, 9 May 2008 02:30:40 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BD95E3A686C for ; Fri, 9 May 2008 02:30:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 487242C017B2C; Fri, 9 May 2008 11:26:40 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRZg4XhowaJv; Fri, 9 May 2008 11:26:40 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 1E3892C00C520; Fri, 9 May 2008 11:26:30 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 11:26:31 +0200 Message-ID: <45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> In-Reply-To: <48240C0F.1080600@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: Acixs2c7z+BxIpkGTg6aE1V3bD1QggAAIG6Q References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net> From: "Saverio Niccolini" To: "Hannes Tschofenig" , "Jan Seedorf" Cc: rucus@ietf.org Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes and all, > at slide 12 of > https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm > Henning lists what the outcome of the work would be, namely: > * mechanisms to convey metrics downstream > * mechanisms to query oracles > * policy languages to allow automated decisions This is exactly what we are proposing since AGES... -1- Can we finally agree on this framework view to be part of the EG planned output? > Working on the specific solutions is not the job of an EG; > this is the work that would be done afterwards in a working group. This is THE unclear point that came out in the BOF, I am personally: -- against specifying 3 specific mechanisms in the EG -- not against specifying 3 class of mechanism (I would be fine with saying we agree with slide 7 of https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) --> but this could also be a separate doc Thus the ONLY unclear point is: -2 do we want to have, in addition to the framework, also a list of 3 class of mechanisms for the follow-up work? If yes, as a single doc with the framework or as a separate one? > Hence, I suggested to write a framework that lists a few > mechanism that make sense when used together. This means > selecting useful building blocks. the useful building blocks are: * mechanisms to convey metrics downstream * mechanisms to query oracles * policy languages to allow automated decisions > I believe we are able to write such a document in the > timeframe of an EG. Then, we move on to the work on the > detailed solutions. We will be for sure able to do it. Let me summarize (I am trying to help get this EG started here) Can we set a deadline for people to answer to -1- and -2- ? What about 2 weeks from now (23rd of May)? After this deadline we will draw conclusions and propose the agreed charter for RUCUS EG and have ADs grant it :-) If there are objections to this please speak Saverio > > Ciao > Hannes > > > Jan Seedorf wrote: > > Dear all, > > > > I would like to make a proposal on how to move forward with > RUCUS (after all, it should be the discussion on this mailing > list that drives RUCUS towards an EG). During the BoF in > Philadelphia, Henning Schulzrinne presented some slides (see > https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1 > .ppt.htm) which in my opinion include some key ideas for > potential RUCUS work and goals on which I have not seen much > discussion on this list (at least not directly): > > > > -- We should keep in mind that attacks and mechanisms (as > countermeasures against unsolicited communications) are > likely to evolve. Thus, RUCUS work should focus on a flexible > "communication glue" for mechanisms to communicate in a > (distributed) setting, or as Henning put it "separate > mechanisms from communication protocols". In that sense, > RUCUS as an EG could/should work out what communication > protocol properties are necessary to achieve this flexible > communication glue. Such communication glue should be > independent of concrete mechanisms and allow for evolving mechanisms. > > > > -- There is a need for distributed communication among > entities (e.g., configuring and communicating authorization > policies, querying oracles, conveying downstream metrics, see > the slides). This includes the need for a common policy > language to enable the communication of authorization > policies. This would allow for automated decisions, so that > for instance based on a) some call characteristics perceived > and b) a policy set by a user (where a) and b) are at > different locations) actions on a SIP message can be taken > (e.g., "forward to mailbox"). Therefore, such communication > glue would need to allow for distributed communication and to > allow mechanisms from different vendors to work together > (something where the e-mail world has failed). > > > > At the BoF in Philly it was agreed to follow the proposal from > > Jonathan Rosenberg to select 3 mechanisms from the ones in RFC 5039 > > and explore these in detail. Following the points above (to make > > distinct that very concrete mechanisms should not be standardised > > because these would only be of limited value due to > evolving attacks), > > I think RUCUS should consider 3 prototypical "classes" of > mechanisms > > as key ones (e.g., identity-based mechanisms, statistics-based > > mechanisms, ... -> to be agreed on) and then work on how > these could > > fit in an overall architecture and what "communication > glue" between > > entities would be necessary for these "classes of > mechanisms" to work > > interoperable in a distributed setting (I believe this lies in the > > spirit of the proposal by Jonathan when he talked about 3 > mechanisms: > > to have RUCUS explore what general communication properties are > > necessary, but limiting the work to 3 classes of mechanisms > in order > > to make the charter achievable in resonable t > im > > e). > > > > I am interested to hear what others think about the slides > Henning presented and the potential goals for RUCUS discussed > above. Please provide comments so that we can find consensus > and confine these ideas towards an updated charter for the > RUCUS EG, convincing the ADs to grant it. > > > > Kind regards, > > Jan > > > > P.S.: Admitedly, some text parts above are taken directly from the > > slides Henning presented > > > > ============================================================ > > Jan Seedorf > > Research Scientist > > NEC Europe Ltd., NEC Laboratories Europe, Network Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-221 > > Fax: +49 (0)6221 4342-155 > > e-mail: jan.seedorf@nw.neclab.eu > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > ============================================================ Dr. Saverio Niccolini NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 9 04:08:44 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A140D3A6822; Fri, 9 May 2008 04:08:44 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA2A3A6822 for ; Fri, 9 May 2008 04:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I6d8kgNdfh9 for ; Fri, 9 May 2008 04:08:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 082AC3A681E for ; Fri, 9 May 2008 04:08:39 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2008 09:18:20 -0000 Received: from dhcp-25-105.ripemtg.ripe.net (EHLO [193.0.25.105]) [193.0.25.105] by mail.gmx.net (mp021) with SMTP; 09 May 2008 11:18:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9hs4Ha+G9Ur9umVRc21NtlQdvJl49fNnEkFXOM+ fyVdrP03xNxpi0 Message-ID: <482416C8.8010407@gmx.net> Date: Fri, 09 May 2008 12:18:00 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Saverio Niccolini References: <481C953A.5000704@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDA64@eris.office> <482408B5.4050802@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDFC9@eris.office> In-Reply-To: <45EDF1C5D301ED41A339796A9F979F720FDFC9@eris.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ? X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Saverio, to have 2 documents as output of the WG sounds good for me. One that focuses on the framework & scenarios and another one that points to the class of mechanisms (considering the other document). Good proposal! Ciao Hannes Saverio Niccolini wrote: > Hannes, > > I am fine with keeping scenarios as Dan described to give people > an idea of what they risk (kind of pitfalls) if they not look carefully > into configuration of certain polcies. > > Actually this is part of what we think would be the direction of RUCUS: > -- "reference scenario": > let's take a reference scenario, e.g. a simple standard SIP one like > slide 11 of Henning's presentation > (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) > and let's add what the pitfalls are (Dan's doc), add the considerations > of David about the problem statement and the ones of Otmar which > people seems to agree on > > -- "framework" or "communication glue" --> see Jan's email > for this we see slide 11 of Henning's presentation (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) > as the best example --> it includes polcies and signalling extensions to > query oracles and allow distirbuted decisions --> it would not hint to > specific solution mechanisms if well defined > > -- "class of mechanisms" -- see also Jan's email > this is what Jonathan proposed at the BOF and people agreed on, > actually we speak about classes since single mechanisms do not make > entire sense at this point in time > > I do not seen any problem with this approach and I hope to see large > consensus, I think this is clean and simple and we can achieve this in > the 6 months of an EG. > > Can we agree on this, write the charter proposal around that, have > ADs convinced and start real work? > > Comments? > > Saverio > > ============================================================ > Dr. Saverio Niccolini > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, May 09, 2008 10:18 AM >> To: Saverio Niccolini >> Cc: Dan York; rucus BoF >> Subject: Re: [Rucus] Any further comments on >> draft-york-sipping-spit-similarity-scenarios-00.txt ? >> >> I agree with you, Saverio. Nevertheless it is a good idea to >> keep the scenarios Dan has described in his document in mind >> and to consider them in the overall solution. >> >> >> Saverio Niccolini wrote: >> >>> Dear Hannes, >>> >>> >>> >>>> I like your document, as mentioned previously already. I >>>> >> shows some >> >>>> of the limitations with systems that use learning of past >>>> >> behavior as >> >>>> their basis for future actions. Some of the statistical techniques >>>> belong to this category. >>>> >>>> >>> we all agree statistical techniques do have limitations, >>> >> but they are >> >>> also powerful and this does not mean they should not be >>> >> considered in >> >>> the RUCUS work >>> >>> I remember all the list of methods indicated by Henning >>> >> during the BOF >> >>> as most promising (check his ppt slides): >>> -- identity-based >>> -- statistics >>> -- price-based >>> >>> For some of the scenarios Dan describes in his draft the >>> >> statistical >> >>> techniques will never come into play: >>> -- "emergency notifications": if you have strong identities >>> >> in place >> >>> and you are sure nobody can steal them, you just need to insert the >>> URIs that are allowed to send "emergency notification" into >>> >> the white >> >>> list --> no need to apply statistics, just work on policy and >>> identity-based mechanisms (statistics are useful here to check >>> misbehaviours) >>> >>> -- Urgent Notification Systems: a bit more complicated but there is >>> always a previous relationship between caller and callee, thus also >>> here one could get around them without statistics but with policies >>> and identity-based mechanisms >>> >>> -- for the other systems I would always repeat what I just wrote: >>> apply policies and identity-based mechanisms >>> >>> The statistics are good when ther eis no previous >>> >> relationship between >> >>> the caller and the callee and this is why they are useful >>> >>> Thus if you want to choose the three class of mechanisms that RUCUS >>> should suggest just choose these three.. >>> >>> Cheers, >>> Saverio >>> >>> >>> >>>> However, the most important question is: What should >>>> >> happen with the >> >>>> document at the end? >>>> Furthermore, the document points to potential problems to >>>> >> a specific >> >>>> category of solutions. For systems that do not rely on learning >>>> techniques these scenarios are not a problem as such. >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> Dan York wrote: >>>> >>>> >>>>> SIPPING & RUCUS, >>>>> >>>>> Because I've had some various pieces of feedback on the >>>>> >>>>> >>>> document, I'm >>>> >>>> >>>>> going to rev draft-york-sipping-spit-similarity-scenarios >>>>> >>>>> >>>> in the next >>>> >>>> >>>>> week or so to incorporate that feedback. Since I'm doing so, I >>>>> thought I'd just ask.... anyone else have comments on: >>>>> >>>>> >>>>> >>>>> >>>>> >> http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios >> >>>> - >>>> >>>> >>>>> 00.txt >>>>> >>>>> Additional scenarios you think I should include.... points of >>>>> clarification... whatever? >>>>> >>>>> Thanks, >>>>> Dan >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Rucus mailing list >>>> Rucus@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rucus >>>> >>>> >>>> >>> ============================================================ >>> Dr. Saverio Niccolini >>> NEC Laboratories Europe, Network Research Division >>> Kurfuerstenanlage 36, D-69115 Heidelberg >>> Tel. +49 (0)6221 4342-118 >>> Fax: +49 (0)6221 4342-155 >>> e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! >>> ============================================================ >>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL Registered in England 2832014 >>> >>> >>> >> _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Fri May 9 04:38:24 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2743A684B; Fri, 9 May 2008 04:38:24 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D753A684B for ; Fri, 9 May 2008 04:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8ttogrLkIXX for ; Fri, 9 May 2008 04:38:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C1FA53A681E for ; Fri, 9 May 2008 04:38:20 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2008 09:48:32 -0000 Received: from dhcp-25-105.ripemtg.ripe.net (EHLO [193.0.25.105]) [193.0.25.105] by mail.gmx.net (mp055) with SMTP; 09 May 2008 11:48:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+5OAoCj5K5zB2Oeu7pZua68JBHq4IdcFrLIb2S44 utK/82Z5iH4B9P Message-ID: <48241DF1.3010501@gmx.net> Date: Fri, 09 May 2008 12:48:33 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Saverio Niccolini References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> In-Reply-To: <45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org, Jan Seedorf Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Saverio, > This is THE unclear point that came out in the BOF, I am personally: > -- against specifying 3 specific mechanisms in the EG > OK > -- not against specifying 3 class of mechanism (I would be fine with saying > we agree with slide 7 of https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) > OK > --> but this could also be a separate doc > > OK > Thus the ONLY unclear point is: > -2 do we want to have, in addition to the framework, also a list > of 3 class of mechanisms for the follow-up work? If yes, as a single > doc with the framework or as a separate one? > I hope that the solution classes are specific enough so that we could then start the details of the work. I personally would like to keep it separate: scenarios&framework could already be quite long. > >> Hence, I suggested to write a framework that lists a few >> mechanism that make sense when used together. This means >> selecting useful building blocks. >> > > the useful building blocks are: > * mechanisms to convey metrics downstream > * mechanisms to query oracles > * policy languages to allow automated decisions > > I understand your preference. >> I believe we are able to write such a document in the >> timeframe of an EG. Then, we move on to the work on the >> detailed solutions. >> > > We will be for sure able to do it. > > Let me summarize (I am trying to help get this EG started here) > Can we set a deadline for people to answer to -1- and -2- ? > What about 2 weeks from now (23rd of May)? > After this deadline we will draw conclusions and propose the > agreed charter for RUCUS EG and have ADs grant it :-) > > If there are objections to this please speak > > Could you briefly compile a drafty draft containing a description of the solution classes? Just to give folks an idea on how it would look like? Ciao Hannes > Saverio > > >> Ciao >> Hannes >> >> >> Jan Seedorf wrote: >> >>> Dear all, >>> >>> I would like to make a proposal on how to move forward with >>> >> RUCUS (after all, it should be the discussion on this mailing >> list that drives RUCUS towards an EG). During the BoF in >> Philadelphia, Henning Schulzrinne presented some slides (see >> https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1 >> .ppt.htm) which in my opinion include some key ideas for >> potential RUCUS work and goals on which I have not seen much >> discussion on this list (at least not directly): >> >>> -- We should keep in mind that attacks and mechanisms (as >>> >> countermeasures against unsolicited communications) are >> likely to evolve. Thus, RUCUS work should focus on a flexible >> "communication glue" for mechanisms to communicate in a >> (distributed) setting, or as Henning put it "separate >> mechanisms from communication protocols". In that sense, >> RUCUS as an EG could/should work out what communication >> protocol properties are necessary to achieve this flexible >> communication glue. Such communication glue should be >> independent of concrete mechanisms and allow for evolving mechanisms. >> >>> -- There is a need for distributed communication among >>> >> entities (e.g., configuring and communicating authorization >> policies, querying oracles, conveying downstream metrics, see >> the slides). This includes the need for a common policy >> language to enable the communication of authorization >> policies. This would allow for automated decisions, so that >> for instance based on a) some call characteristics perceived >> and b) a policy set by a user (where a) and b) are at >> different locations) actions on a SIP message can be taken >> (e.g., "forward to mailbox"). Therefore, such communication >> glue would need to allow for distributed communication and to >> allow mechanisms from different vendors to work together >> (something where the e-mail world has failed). >> >>> At the BoF in Philly it was agreed to follow the proposal from >>> Jonathan Rosenberg to select 3 mechanisms from the ones in RFC 5039 >>> and explore these in detail. Following the points above (to make >>> distinct that very concrete mechanisms should not be standardised >>> because these would only be of limited value due to >>> >> evolving attacks), >> >>> I think RUCUS should consider 3 prototypical "classes" of >>> >> mechanisms >> >>> as key ones (e.g., identity-based mechanisms, statistics-based >>> mechanisms, ... -> to be agreed on) and then work on how >>> >> these could >> >>> fit in an overall architecture and what "communication >>> >> glue" between >> >>> entities would be necessary for these "classes of >>> >> mechanisms" to work >> >>> interoperable in a distributed setting (I believe this lies in the >>> spirit of the proposal by Jonathan when he talked about 3 >>> >> mechanisms: >> >>> to have RUCUS explore what general communication properties are >>> necessary, but limiting the work to 3 classes of mechanisms >>> >> in order >> >>> to make the charter achievable in resonable t >>> >> im >> >>> e). >>> >>> I am interested to hear what others think about the slides >>> >> Henning presented and the potential goals for RUCUS discussed >> above. Please provide comments so that we can find consensus >> and confine these ideas towards an updated charter for the >> RUCUS EG, convincing the ADs to grant it. >> >>> Kind regards, >>> Jan >>> >>> P.S.: Admitedly, some text parts above are taken directly from the >>> slides Henning presented >>> >>> ============================================================ >>> Jan Seedorf >>> Research Scientist >>> NEC Europe Ltd., NEC Laboratories Europe, Network Division >>> Kurfuerstenanlage 36, D-69115 Heidelberg >>> Tel. +49 (0)6221 4342-221 >>> Fax: +49 (0)6221 4342-155 >>> e-mail: jan.seedorf@nw.neclab.eu >>> ============================================================ >>> NEC Europe Limited Registered Office: NEC House, >>> 1 Victoria Road, London W3 6BL Registered in England 2832014 >>> _______________________________________________ >>> Rucus mailing list >>> Rucus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rucus >>> >>> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> > > > ============================================================ > Dr. Saverio Niccolini > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat May 10 00:16:49 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8CB3A67A1; Sat, 10 May 2008 00:16:49 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E917D3A67A1 for ; Sat, 10 May 2008 00:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUOZWyF-dppR for ; Sat, 10 May 2008 00:16:47 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CA4893A65A5 for ; Sat, 10 May 2008 00:16:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3CF7D2C00C521; Sat, 10 May 2008 09:12:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBY+c9E20-u8; Sat, 10 May 2008 09:12:09 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 1ABC32C0012A6; Sat, 10 May 2008 09:11:59 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 10 May 2008 09:11:58 +0200 Message-ID: <45EDF1C5D301ED41A339796A9F979F720FE0CC@eris.office> In-Reply-To: <48241DF1.3010501@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: Acixynp4s9ArNm0tTgaOFggHfin+qQAoREhA References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office><48240C0F.1080600@gmx.net><45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> <48241DF1.3010501@gmx.net> From: "Saverio Niccolini" To: "Hannes Tschofenig" Cc: rucus@ietf.org, Jan Seedorf Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > >> Hence, I suggested to write a framework that lists a few mechanism > >> that make sense when used together. This means selecting useful > >> building blocks. > >> > > > > the useful building blocks are: > > * mechanisms to convey metrics downstream > > * mechanisms to query oracles > > * policy languages to allow automated decisions > > > > > I understand your preference. That is my preference AND what is described in slide 11 and 12 of Henning's presentation: https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm Citing Henning (slide 12): "What's to do? - Need for glue to allow distirbuted mechanisms: -a- mechanisms to convey metrics downstream -b- mechanisms to query oracle -c- policy language to allow automated decisions" if you look at -a- and -b- this is what we tried to describe in SPITSTOP draft (and others like spam score) -c- is your policy draft, plus maybe some feedbacks from users (that would allow to trigger policies automatically) and, in my opinion, these are the only things that makes really sense right now for the EG (as you originally wrote in the BOF proposal) --> and of course the idea of Jonathan that popped up in the BOF can be added as well thus we are all happy and can really start working on the EG :-) Ciao, Saverio ============================================================ Dr. Saverio Niccolini NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat May 10 14:54:40 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FE93A6A16; Sat, 10 May 2008 14:54:40 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2E43A6A16 for ; Sat, 10 May 2008 14:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIV5W71aP0mm for ; Sat, 10 May 2008 14:54:38 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 67A3A3A6A14 for ; Sat, 10 May 2008 14:54:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6F24D2C00C520; Sat, 10 May 2008 23:54:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swqEpZoqJFfU; Sat, 10 May 2008 23:54:27 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 44FEE2C0012A6; Sat, 10 May 2008 23:54:17 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 10 May 2008 23:54:14 +0200 Message-ID: <3F2392DE5DFB08489CCFB46BC4ED7D6E101031@eris.office> In-Reply-To: <48240C0F.1080600@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: AcixrzVrriH6fN0jTdSzx8sgcR94JABNXJug References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net> From: "Jan Seedorf" To: "Hannes Tschofenig" Cc: rucus@ietf.org Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear Hannes, > Working on the specific solutions is not the job of an EG; > this is the work that would be done afterwards in a working group. You are right, in the scope of a 6 months EG solutions cannot be developed, I am aware of that and was not trying to suggest that. My idea (based on Henning's slides) is that the EG should explore what kind of "communication glue" (as described in my last e-mail) is necessary to make the (to be decided on) three classes of mechanisms work together, specifically under the two in my opinion important considerations a) mechanisms and attacks will evolve and b) distributed communication between entities is necessary. I was not trying to suggest that RUCUS should develop solutions for this, but rather that RUCUS should confine requirements/necessary properties of such a "communication glue" (for a potential follow-up WG to have in a document) with respect to three classes of mechanisms (in order to focus and have achievable goals as proposed by Jonathan). > Hence, I suggested to write a framework that lists a few > mechanism that make sense when used together. This means > selecting useful building blocks. I believe this is not far from what I suggested in my e-mail. The difference may be that I think RUCUS should explore what communication is necessary between these building blocks as well. > I believe we are able to write such a document in the > timeframe of an EG. Then, we move on to the work on the > detailed solutions. I share that view. - Jan > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, May 09, 2008 10:32 AM > To: Jan Seedorf > Cc: rucus@ietf.org > Subject: Re: [Rucus] how to move forward towards an EG > > Hi Jan, > > at slide 12 of > https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm > Henning lists what the outcome of the work would be, namely: > * mechanisms to convey metrics downstream > * mechanisms to query oracles > * policy languages to allow automated decisions > > Working on the specific solutions is not the job of an EG; > this is the work that would be done afterwards in a working group. > > Hence, what we would want todo in an EG is to decide on the > mechanisms one would pick (in Henning's case the above > three). Other folks may have different mechanisms in mind. > > Jonathan proposed to again describe the mechanisms as an > excercise to pick a certain number of mechanisms. > For example, one would describe what white lists do, what > features they provide, where they provide advantages and > where they fail. > > I considered this as a useless excercise for 2 reasons: > a) we already know the mechanisms. Their properties are > already known and described. See for example RFC 5039 > b) many mechanisms need to be used in concert with some other > mechanisms > (example: strong identities are nice but you need to make an > authorization decision afterwards; white lists are useless if > there is no strong identity mechanisms, etc. ) > > Hence, I suggested to write a framework that lists a few > mechanism that make sense when used together. This means > selecting useful building blocks. > > I believe we are able to write such a document in the > timeframe of an EG. Then, we move on to the work on the > detailed solutions. > > Ciao > Hannes > > > Jan Seedorf wrote: > > Dear all, > > > > I would like to make a proposal on how to move forward with > RUCUS (after all, it should be the discussion on this mailing > list that drives RUCUS towards an EG). During the BoF in > Philadelphia, Henning Schulzrinne presented some slides (see > https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1 > .ppt.htm) which in my opinion include some key ideas for > potential RUCUS work and goals on which I have not seen much > discussion on this list (at least not directly): > > > > -- We should keep in mind that attacks and mechanisms (as > countermeasures against unsolicited communications) are > likely to evolve. Thus, RUCUS work should focus on a flexible > "communication glue" for mechanisms to communicate in a > (distributed) setting, or as Henning put it "separate > mechanisms from communication protocols". In that sense, > RUCUS as an EG could/should work out what communication > protocol properties are necessary to achieve this flexible > communication glue. Such communication glue should be > independent of concrete mechanisms and allow for evolving mechanisms. > > > > -- There is a need for distributed communication among > entities (e.g., configuring and communicating authorization > policies, querying oracles, conveying downstream metrics, see > the slides). This includes the need for a common policy > language to enable the communication of authorization > policies. This would allow for automated decisions, so that > for instance based on a) some call characteristics perceived > and b) a policy set by a user (where a) and b) are at > different locations) actions on a SIP message can be taken > (e.g., "forward to mailbox"). Therefore, such communication > glue would need to allow for distributed communication and to > allow mechanisms from different vendors to work together > (something where the e-mail world has failed). > > > > At the BoF in Philly it was agreed to follow the proposal from > > Jonathan Rosenberg to select 3 mechanisms from the ones in > RFC 5039 and explore these in detail. Following the points > above (to make distinct that very concrete mechanisms should > not be standardised because these would only be of limited > value due to evolving attacks), I think RUCUS should consider > 3 prototypical "classes" of mechanisms as key ones (e.g., > identity-based mechanisms, statistics-based mechanisms, ... > -> to be agreed on) and then work on how these could fit in > an overall architecture and what "communication glue" between > entities would be necessary for these "classes of mechanisms" > to work interoperable in a distributed setting (I believe > this lies in the spirit of the proposal by Jonathan when he > talked about 3 mechanisms: to have RUCUS explore what general > communication properties are necessary, but limiting the work > to 3 classes of mechanisms in order to make the charter > achievable in resonable tim e). > > > > I am interested to hear what others think about the slides > Henning presented and the potential goals for RUCUS discussed > above. Please provide comments so that we can find consensus > and confine these ideas towards an updated charter for the > RUCUS EG, convincing the ADs to grant it. > > > > Kind regards, > > Jan > > > > P.S.: Admitedly, some text parts above are taken directly from the > > slides Henning presented > > > > ============================================================ > > Jan Seedorf > > Research Scientist > > NEC Europe Ltd., NEC Laboratories Europe, Network Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-221 > > Fax: +49 (0)6221 4342-155 > > e-mail: jan.seedorf@nw.neclab.eu > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 12 02:03:45 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4C028C1AB; Mon, 12 May 2008 02:03:45 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8131428C1AB for ; Mon, 12 May 2008 02:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYbJxhgfqJcA for ; Mon, 12 May 2008 02:03:42 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 3EBA028C19B for ; Mon, 12 May 2008 02:03:39 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m4C8RLQT000406; Mon, 12 May 2008 10:27:21 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 12 May 2008 10:27:21 +0200 Message-ID: <4827FF66.7000303@alcatel-lucent.fr> Date: Mon, 12 May 2008 10:27:18 +0200 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Saverio Niccolini References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> In-Reply-To: <45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> X-OriginalArrivalTime: 12 May 2008 08:27:21.0827 (UTC) FILETIME=[FFBBEB30:01C8B409] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: rucus@ietf.org, Jan Seedorf Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I mostly agree with Saverio's views: Saverio Niccolini wrote: > -1- Can we finally agree on this framework view to be part of the EG planned output? Yes, of course. >> Working on the specific solutions is not the job of an EG; >> this is the work that would be done afterwards in a working group. >> > > This is THE unclear point that came out in the BOF, I am personally: > -- against specifying 3 specific mechanisms in the EG > same for me. > -- not against specifying 3 class of mechanism (I would be fine with saying > we agree with slide 7 of https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) > --> but this could also be a separate doc > Yes > > Thus the ONLY unclear point is: > -2 do we want to have, in addition to the framework, also a list > of 3 class of mechanisms for the follow-up work? If yes, as a single > doc with the framework or as a separate one? > I am in favor of "3 class of mechanisms" document(s), probably as separate documents because I feel it is better to clearly categorize the solution space... >> Hence, I suggested to write a framework that lists a few >> mechanism that make sense when used together. This means >> selecting useful building blocks. >> > > the useful building blocks are: > * mechanisms to convey metrics downstream > * mechanisms to query oracles > * policy languages to allow automated decisions >> I believe we are able to write such a document in the >> timeframe of an EG. Then, we move on to the work on the >> detailed solutions. >> Perfect, when do we start? : Thomas _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 12 02:26:45 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D90A3A682B; Mon, 12 May 2008 02:26:45 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCC628C1D9 for ; Mon, 12 May 2008 02:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM2VfTXIw8zx for ; Mon, 12 May 2008 02:26:42 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1B3E23A6785 for ; Mon, 12 May 2008 02:26:41 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4C9Pi2s003806; Mon, 12 May 2008 12:25:53 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 12:25:29 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 12:25:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 12:25:29 +0300 Message-ID: In-Reply-To: <4827FF66.7000303@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: Aci0Dx0U/61j9OWuRjqDZf9LS77bqwAAtcUQ References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net><45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> <4827FF66.7000303@alcatel-lucent.fr> From: To: , X-OriginalArrivalTime: 12 May 2008 09:25:29.0378 (UTC) FILETIME=[1E79F820:01C8B412] X-Nokia-AV: Clean Cc: rucus@ietf.org, Jan.Seedorf@nw.neclab.eu Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org >> >> Thus the ONLY unclear point is: >> -2 do we want to have, in addition to the framework, also a >list of 3 >> class of mechanisms for the follow-up work? If yes, as a single doc >> with the framework or as a separate one? >> >I am in favor of "3 class of mechanisms" document(s), probably >as separate documents because I feel it is better to clearly >categorize the solution space... > Thomas, please note that the 3 classes of mechanisms being described in the Exploratory Group itself are at a high-level rather than actually describing the detailed solutions. Hence, we are talking about 2 pages per class at a maximum. Ciao Hannes _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 12 02:43:16 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD35A3A6848; Mon, 12 May 2008 02:43:16 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA00B3A6848 for ; Mon, 12 May 2008 02:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfCh8jf+duzV for ; Mon, 12 May 2008 02:43:15 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9C9773A6785 for ; Mon, 12 May 2008 02:43:14 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4C9fxVl015218; Mon, 12 May 2008 12:42:23 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 12:41:36 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 12:41:36 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 12:41:36 +0300 Message-ID: In-Reply-To: <48280F26.5060808@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: Aci0FB5Vv9aXqP3MRFWfypbJc5eyzQAABqEg References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net><45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> <4827FF66.7000303@alcatel-lucent.fr> <48280F26.5060808@alcatel-lucent.fr> From: To: X-OriginalArrivalTime: 12 May 2008 09:41:36.0578 (UTC) FILETIME=[5EF8FA20:01C8B414] X-Nokia-AV: Clean Cc: rucus@ietf.org, Jan.Seedorf@nw.neclab.eu, Saverio.Niccolini@nw.neclab.eu Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Right. The reason why I say that is that the EG is not the place todo the detailed solution work but rather the place todo the preparation for the work that happens in some working group later. Ciao Hannes >-----Original Message----- >From: ext Thomas Froment [mailto:Thomas.Froment@alcatel-lucent.fr] >Sent: 12 May, 2008 12:35 >To: Tschofenig Hannes (NSN - FI/Espoo) >Cc: Saverio.Niccolini@nw.neclab.eu; rucus@ietf.org; >Jan.Seedorf@nw.neclab.eu >Subject: Re: [Rucus] how to move forward towards an EG > >hannes.tschofenig@nsn.com wrote: >> >> Thomas, please note that the 3 classes of mechanisms being described >> in the Exploratory Group itself are at a high-level rather than >> actually describing the detailed solutions. >> Hence, we are talking about 2 pages per class at a maximum. >> >Well, if it's only 2 pages, that's true it is not mandatorily >worth a separate document, but could have been a way to split >the work more easily... >This is not an important issue anyway... > >Ciao :) >Thomas > > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 12 02:43:56 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B3528C250; Mon, 12 May 2008 02:43:56 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AF828C246 for ; Mon, 12 May 2008 02:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7k9sw+B7Sti for ; Mon, 12 May 2008 02:43:54 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 0855B28C216 for ; Mon, 12 May 2008 02:43:53 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m4C9YXI4006189; Mon, 12 May 2008 11:34:33 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Mon, 12 May 2008 11:34:33 +0200 Message-ID: <48280F26.5060808@alcatel-lucent.fr> Date: Mon, 12 May 2008 11:34:30 +0200 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: hannes.tschofenig@nsn.com References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net><45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> <4827FF66.7000303@alcatel-lucent.fr> In-Reply-To: X-OriginalArrivalTime: 12 May 2008 09:34:33.0712 (UTC) FILETIME=[62ECBF00:01C8B413] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: rucus@ietf.org, Jan.Seedorf@nw.neclab.eu, Saverio.Niccolini@nw.neclab.eu Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org hannes.tschofenig@nsn.com wrote: > > Thomas, please note that the 3 classes of mechanisms being described in > the Exploratory Group itself are at a high-level rather than actually > describing the detailed solutions. > Hence, we are talking about 2 pages per class at a maximum. > Well, if it's only 2 pages, that's true it is not mandatorily worth a separate document, but could have been a way to split the work more easily... This is not an important issue anyway... Ciao :) Thomas _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 12 06:57:11 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64DB3A6885; Mon, 12 May 2008 06:57:11 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD273A681C for ; Mon, 12 May 2008 06:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdszFjBRilnO for ; Mon, 12 May 2008 06:57:09 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1559D3A67B6 for ; Mon, 12 May 2008 06:57:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DD49E2C020492; Mon, 12 May 2008 15:55:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq6vNmG6OuwP; Mon, 12 May 2008 15:55:29 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id B4C852C0012A6; Mon, 12 May 2008 15:55:14 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 15:55:13 +0200 Message-ID: <3F2392DE5DFB08489CCFB46BC4ED7D6E101066@eris.office> In-Reply-To: <4827FF66.7000303@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: Aci0ClK+CLJ9SGxsS0myVaClVkfJYAALRw6Q References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net> <45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> <4827FF66.7000303@alcatel-lucent.fr> From: "Jan Seedorf" To: "Thomas Froment" , "Saverio Niccolini" Cc: rucus@ietf.org Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear Thomas, > > Thus the ONLY unclear point is: > > -2 do we want to have, in addition to the framework, also a > list of 3 > > class of mechanisms for the follow-up work? If yes, as a single doc > > with the framework or as a separate one? > > > I am in favor of "3 class of mechanisms" document(s), > probably as separate documents because I feel it is better to > clearly categorize the solution space... I agree that two separate documents (most probably referring to each other) make sense. However, at this stage I think it is not so important if it will be one or two documents in the end. I am rather interested if others agree on the path described in my mail a couple of days ago and then further discussed by Hannes and Saverio on this list ... Kind regards, Jan > -----Original Message----- > From: Thomas Froment [mailto:Thomas.Froment@alcatel-lucent.fr] > Sent: Monday, May 12, 2008 10:27 AM > To: Saverio Niccolini > Cc: Hannes Tschofenig; Jan Seedorf; rucus@ietf.org > Subject: Re: [Rucus] how to move forward towards an EG > > I mostly agree with Saverio's views: > > Saverio Niccolini wrote: > > -1- Can we finally agree on this framework view to be part > of the EG planned output? > Yes, of course. > >> Working on the specific solutions is not the job of an EG; this is > >> the work that would be done afterwards in a working group. > >> > > > > This is THE unclear point that came out in the BOF, I am personally: > > -- against specifying 3 specific mechanisms in the EG > > > same for me. > > -- not against specifying 3 class of mechanism (I would be > fine with > > saying we agree with slide 7 of > > > https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm > > ) > > --> but this could also be a separate doc > > > Yes > > > > Thus the ONLY unclear point is: > > -2 do we want to have, in addition to the framework, also a > list of 3 > > class of mechanisms for the follow-up work? If yes, as a single doc > > with the framework or as a separate one? > > > I am in favor of "3 class of mechanisms" document(s), > probably as separate documents because I feel it is better to > clearly categorize the solution space... > > >> Hence, I suggested to write a framework that lists a few mechanism > >> that make sense when used together. This means selecting useful > >> building blocks. > >> > > > > the useful building blocks are: > > * mechanisms to convey metrics downstream > > * mechanisms to query oracles > > * policy languages to allow automated decisions > >> I believe we are able to write such a document in the > timeframe of an > >> EG. Then, we move on to the work on the detailed solutions. > >> > Perfect, when do we start? : > > Thomas > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon May 12 07:15:32 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9903C3A689C; Mon, 12 May 2008 07:15:32 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF053A6801 for ; Mon, 12 May 2008 07:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCfSqMmcDmxq for ; Mon, 12 May 2008 07:15:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6F9863A67B6 for ; Mon, 12 May 2008 07:15:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 23DE42C020481; Mon, 12 May 2008 15:43:59 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oi3SO9TMTqK; Mon, 12 May 2008 15:43:59 +0200 (CEST) Received: from eris.office (eris.office [192.168.24.5]) by smtp0.neclab.eu (Postfix) with ESMTP id 003382C01C9E9; Mon, 12 May 2008 15:43:43 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 15:43:42 +0200 Message-ID: <3F2392DE5DFB08489CCFB46BC4ED7D6E101064@eris.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] how to move forward towards an EG Thread-Index: Aci0FB5Vv9aXqP3MRFWfypbJc5eyzQAABqEgAAhdvAA= References: <3F2392DE5DFB08489CCFB46BC4ED7D6E100E24@eris.office> <48240C0F.1080600@gmx.net><45EDF1C5D301ED41A339796A9F979F720FDFDD@eris.office> <4827FF66.7000303@alcatel-lucent.fr> <48280F26.5060808@alcatel-lucent.fr> From: "Jan Seedorf" To: , Cc: rucus@ietf.org, Saverio Niccolini Subject: Re: [Rucus] how to move forward towards an EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear Hannes, > The reason why I say that is that the EG is not the place > todo the detailed solution work but rather the place todo the > preparation for the work that happens in some working group later. I think this is clear by now and was explicitly pointed out at the BoF in Philly. But it probably cannot hurt to remind everyone once in a while that RUCUS (if granted) will be an EG, not a WG. - Jan > -----Original Message----- > From: hannes.tschofenig@nsn.com [mailto:hannes.tschofenig@nsn.com] > Sent: Monday, May 12, 2008 11:42 AM > To: Thomas.Froment@alcatel-lucent.fr > Cc: Saverio Niccolini; rucus@ietf.org; Jan Seedorf > Subject: RE: [Rucus] how to move forward towards an EG > > Right. > > The reason why I say that is that the EG is not the place > todo the detailed solution work but rather the place todo the > preparation for the work that happens in some working group later. > > Ciao > Hannes > > >-----Original Message----- > >From: ext Thomas Froment [mailto:Thomas.Froment@alcatel-lucent.fr] > >Sent: 12 May, 2008 12:35 > >To: Tschofenig Hannes (NSN - FI/Espoo) > >Cc: Saverio.Niccolini@nw.neclab.eu; rucus@ietf.org; > >Jan.Seedorf@nw.neclab.eu > >Subject: Re: [Rucus] how to move forward towards an EG > > > >hannes.tschofenig@nsn.com wrote: > >> > >> Thomas, please note that the 3 classes of mechanisms being > described > >> in the Exploratory Group itself are at a high-level rather than > >> actually describing the detailed solutions. > >> Hence, we are talking about 2 pages per class at a maximum. > >> > >Well, if it's only 2 pages, that's true it is not > mandatorily worth a > >separate document, but could have been a way to split the work more > >easily... > >This is not an important issue anyway... > > > >Ciao :) > >Thomas > > > > > > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus