From rucus-bounces@ietf.org Wed Nov 5 08:02:14 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 3B8C23A6944; Wed, 5 Nov 2008 08:02:14 -0800 (PST) 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 9442F3A6944 for ; Wed, 5 Nov 2008 08:02:13 -0800 (PST) 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 PhoFCI+6hcmC for ; Wed, 5 Nov 2008 08:02:12 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id A59083A63D2 for ; Wed, 5 Nov 2008 08:02:12 -0800 (PST) Received: from [66.65.228.203] (account dyork HELO pc-00144.lodestar2.dyndns.org) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 36776669 for rucus@ietf.org; Wed, 05 Nov 2008 16:02:09 +0000 Message-Id: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> From: Dan York To: rucus BoF Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 5 Nov 2008 10:59:59 -0500 X-Mailer: Apple Mail (2.929.2) Subject: [Rucus] Should we just declare RUCUS dead and move on? (Or have we already?) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Folks, I notice that RUCUS is (understandably) yet again not on the agenda for IETF 73. It was also not on the agenda for IETF 72 and was last held at IETF 71 **8 months ago** in March in Philadelphia. At IETF 71, we talked about creating a *6-month* Exploratory Group (EG) to explore some of the basic issues and decide whether or not we needed to move into a WG. That was to be a 6-month plan, but here we are 8 months later and we haven't started that 6-month window... Based on past email, it seems to me that we are waiting upon the "blessing" of the ADs to launch the EG before we begin the work. Given how taxed for time the ADs appear to be, what is the likelihood for this to occur? Do we need to do something drastic like hide Cullen's MacBook Air at IETF 73 when he leaves it on a chair to go speak at the mic and refuse to give it back to him until he provides an answer? (Thus creating a rucus about RUCUS.) I'm joking on that point (as Cullen will now avoid being near me for all of IETF 73!), but I am serious that I think we need to figure out what we are doing with this list and group. If we want to move this body of work forward, can the RUCUS co-chairs *please* find out from the ADs about RUCUS becoming an EG? Or should we just start working on I-D's and acting as if this IS a BOF/EG? (Do we all have time to do so?) Or if we think that the work we've talked about doing in RUCUS is simply too difficult to do or at least to do within the IETF, let's just shut down the list and move on. We all have a zillion other things to do. 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 Wed Nov 5 08:12:55 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 18F343A6BE4; Wed, 5 Nov 2008 08:12:55 -0800 (PST) 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 560803A6B90 for ; Wed, 5 Nov 2008 08:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[AWL=1.213, 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 0LX5qfD03mhA for ; Wed, 5 Nov 2008 08:12:52 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B80D73A69EA for ; Wed, 5 Nov 2008 08:12:51 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA5GCk0V018070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Nov 2008 17:12:46 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA5GCi8u009243; Wed, 5 Nov 2008 17:12:46 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 17:12:45 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Nov 2008 17:12:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Nov 2008 18:12:42 +0200 Message-ID: In-Reply-To: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Should we just declare RUCUS dead and move on? (Or have wealready?) Thread-Index: Ack/X98SGYXBwkAyTZevoscGXLjBMwAAJdTw References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Dan York" , "rucus BoF" X-OriginalArrivalTime: 05 Nov 2008 16:12:44.0890 (UTC) FILETIME=[564AF3A0:01C93F61] Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or have wealready?) 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, you are right that the Exploratory Group (EG) does not seem to be a workable concept for the IETF with the huge amount of overhead. >From the BOF chair point of view the preparation for the EG is finished some time ago. We submitted the charter with the request for creating an EG to the ADs. I was obviously hoping that this could be executed fast. I cannot create the group myself, as you know. Still doing the work regardless whether a BOF exists is certainly a good idea. Ciao Hannes PS: I worked on a draft for the submission deadline but did not submit since Henning and I believe it needs more work. >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of ext Dan York >Sent: 05 November, 2008 18:00 >To: rucus BoF >Subject: [Rucus] Should we just declare RUCUS dead and move >on? (Or have wealready?) > >Folks, > >I notice that RUCUS is (understandably) yet again not on the >agenda for IETF 73. It was also not on the agenda for IETF 72 >and was last held at IETF 71 **8 months ago** in March in >Philadelphia. At IETF 71, we talked about creating a >*6-month* Exploratory Group (EG) to explore some of the basic >issues and decide whether or not we needed to move into a WG. > >That was to be a 6-month plan, but here we are 8 months later >and we haven't started that 6-month window... > >Based on past email, it seems to me that we are waiting upon the >"blessing" of the ADs to launch the EG before we begin the work. >Given how taxed for time the ADs appear to be, what is the >likelihood for this to occur? Do we need to do something >drastic like hide Cullen's MacBook Air at IETF 73 when he >leaves it on a chair to go speak at the mic and refuse to give >it back to him until he provides an answer? (Thus creating a >rucus about RUCUS.) > >I'm joking on that point (as Cullen will now avoid being near >me for all of IETF 73!), but I am serious that I think we need >to figure out what we are doing with this list and group. > >If we want to move this body of work forward, can the RUCUS co-chairs >*please* find out from the ADs about RUCUS becoming an EG? > >Or should we just start working on I-D's and acting as if this >IS a BOF/EG? (Do we all have time to do so?) > >Or if we think that the work we've talked about doing in RUCUS >is simply too difficult to do or at least to do within the >IETF, let's just shut down the list and move on. We all have >a zillion other things to do. > >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 Wed Nov 5 08:39: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 722A53A6B2D; Wed, 5 Nov 2008 08:39:18 -0800 (PST) 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 3CA443A6B2D for ; Wed, 5 Nov 2008 08:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RECV_BEZEQINT_B=0.763] 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 dgdW3Bwn78WA for ; Wed, 5 Nov 2008 08:39:16 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 16A4A3A680E for ; Wed, 5 Nov 2008 08:39:16 -0800 (PST) Received: from [10.0.1.197] (bzq-219-150-62.static.bezeqint.net [62.219.150.62]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1KxlPQ03dd-0004u5; Wed, 05 Nov 2008 17:39:11 +0100 Message-Id: <1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> From: David Schwartz To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 5 Nov 2008 18:39:06 +0200 References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> X-Mailer: Apple Mail (2.924) X-Provags-ID: V01U2FsdGVkX18Yhi3qUHYM8VSsk0sU7Xm00GSN99ojoEVM2d+ eNFRWUgHpY82/wKmN4VdPBKJZjsmzo1qF871MmvBtmJID6PJkb 8n9reHgjp16NcqT3LQdhQ== Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or have wealready?) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Dan, Hannes I myself have been holding off pending some resolution. As it is I have a very hard time justifying time I spend on IETF related work. I would love to see the EG or better yet a WG formed sooner rather than later. Just my two cents, D. On Nov 5, 2008, at 6:12 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Dan, > > you are right that the Exploratory Group (EG) does not seem to be a > workable concept for the IETF with the huge amount of overhead. > > From the BOF chair point of view the preparation for the EG is > finished > some time ago. We submitted the charter with the request for > creating an > EG to the ADs. I was obviously hoping that this could be executed > fast. > I cannot create the group myself, as you know. > > Still doing the work regardless whether a BOF exists is certainly a > good > idea. > > Ciao > Hannes > > PS: I worked on a draft for the submission deadline but did not submit > since Henning and I believe it needs more work. > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of ext Dan York >> Sent: 05 November, 2008 18:00 >> To: rucus BoF >> Subject: [Rucus] Should we just declare RUCUS dead and move >> on? (Or have wealready?) >> >> Folks, >> >> I notice that RUCUS is (understandably) yet again not on the >> agenda for IETF 73. It was also not on the agenda for IETF 72 >> and was last held at IETF 71 **8 months ago** in March in >> Philadelphia. At IETF 71, we talked about creating a >> *6-month* Exploratory Group (EG) to explore some of the basic >> issues and decide whether or not we needed to move into a WG. >> >> That was to be a 6-month plan, but here we are 8 months later >> and we haven't started that 6-month window... >> >> Based on past email, it seems to me that we are waiting upon the >> "blessing" of the ADs to launch the EG before we begin the work. >> Given how taxed for time the ADs appear to be, what is the >> likelihood for this to occur? Do we need to do something >> drastic like hide Cullen's MacBook Air at IETF 73 when he >> leaves it on a chair to go speak at the mic and refuse to give >> it back to him until he provides an answer? (Thus creating a >> rucus about RUCUS.) >> >> I'm joking on that point (as Cullen will now avoid being near >> me for all of IETF 73!), but I am serious that I think we need >> to figure out what we are doing with this list and group. >> >> If we want to move this body of work forward, can the RUCUS co-chairs >> *please* find out from the ADs about RUCUS becoming an EG? >> >> Or should we just start working on I-D's and acting as if this >> IS a BOF/EG? (Do we all have time to do so?) >> >> Or if we think that the work we've talked about doing in RUCUS >> is simply too difficult to do or at least to do within the >> IETF, let's just shut down the list and move on. We all have >> a zillion other things to do. >> >> 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 > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Nov 6 00:37:08 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 53C2E3A68B2; Thu, 6 Nov 2008 00:37:08 -0800 (PST) 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 A64A53A6969 for ; Thu, 6 Nov 2008 00:37:07 -0800 (PST) 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 lKyReCRiYzqH for ; Thu, 6 Nov 2008 00:37:06 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4703B3A682C for ; Thu, 6 Nov 2008 00:37:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A51D12C01C8EC; Thu, 6 Nov 2008 09:37:03 +0100 (CET) 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 8cmqJYE0sX79; Thu, 6 Nov 2008 09:37:03 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 73ECB2C0012CA; Thu, 6 Nov 2008 09:36:48 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 09:35:23 +0100 Message-ID: <547F018265F92642B577B986577D671C441AC6@VENUS.office> In-Reply-To: <1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) Thread-Index: Ack/ZRjjHCPDIcsxS0iqGjkLUwr6RAAhE+kw References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> <1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> From: "Saverio Niccolini" To: "David Schwartz" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) 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 Having a formal EG/WG formed is definitely a good reason for us to spend time on it (as we have resources to do chartered work and not every work we like) and this is what we did so far trying collaborating to form the EG (spending enough time I think) But I also know that Cullen is doing his best to get this done, he just needs some more time to put the right things in place and finding the right people to lead this effort, remember that there is no EG charted so far (it is just an experiment IETF started some time ago) and maybe IETF leaders are cautious on this (they do not want to charter an experiment unless they strongly believe is going to be successful) Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group 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: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of David Schwartz > Sent: Wednesday, November 05, 2008 5:39 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: rucus BoF > Subject: Re: [Rucus] Should we just declare RUCUS dead and > move on? (Or havewealready?) > > Hi Dan, Hannes > > I myself have been holding off pending some resolution. As it > is I have a very hard time justifying time I spend on IETF > related work. > > I would love to see the EG or better yet a WG formed sooner > rather than later. > > Just my two cents, > > D. > > On Nov 5, 2008, at 6:12 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > Hi Dan, > > > > you are right that the Exploratory Group (EG) does not seem to be a > > workable concept for the IETF with the huge amount of overhead. > > > > From the BOF chair point of view the preparation for the EG is > > finished some time ago. We submitted the charter with the > request for > > creating an EG to the ADs. I was obviously hoping that this > could be > > executed fast. > > I cannot create the group myself, as you know. > > > > Still doing the work regardless whether a BOF exists is certainly a > > good idea. > > > > Ciao > > Hannes > > > > PS: I worked on a draft for the submission deadline but did > not submit > > since Henning and I believe it needs more work. > > > >> -----Original Message----- > >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On > >> Behalf Of ext Dan York > >> Sent: 05 November, 2008 18:00 > >> To: rucus BoF > >> Subject: [Rucus] Should we just declare RUCUS dead and > move on? (Or > >> have wealready?) > >> > >> Folks, > >> > >> I notice that RUCUS is (understandably) yet again not on > the agenda > >> for IETF 73. It was also not on the agenda for IETF 72 and > was last > >> held at IETF 71 **8 months ago** in March in Philadelphia. > At IETF > >> 71, we talked about creating a > >> *6-month* Exploratory Group (EG) to explore some of the > basic issues > >> and decide whether or not we needed to move into a WG. > >> > >> That was to be a 6-month plan, but here we are 8 months > later and we > >> haven't started that 6-month window... > >> > >> Based on past email, it seems to me that we are waiting upon the > >> "blessing" of the ADs to launch the EG before we begin the work. > >> Given how taxed for time the ADs appear to be, what is the > likelihood > >> for this to occur? Do we need to do something drastic like hide > >> Cullen's MacBook Air at IETF 73 when he leaves it on a chair to go > >> speak at the mic and refuse to give it back to him until > he provides > >> an answer? (Thus creating a rucus about RUCUS.) > >> > >> I'm joking on that point (as Cullen will now avoid being > near me for > >> all of IETF 73!), but I am serious that I think we need to > figure out > >> what we are doing with this list and group. > >> > >> If we want to move this body of work forward, can the > RUCUS co-chairs > >> *please* find out from the ADs about RUCUS becoming an EG? > >> > >> Or should we just start working on I-D's and acting as if > this IS a > >> BOF/EG? (Do we all have time to do so?) > >> > >> Or if we think that the work we've talked about doing in RUCUS is > >> simply too difficult to do or at least to do within the > IETF, let's > >> just shut down the list and move on. We all have a zillion other > >> things to do. > >> > >> 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 > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > _______________________________________________ > 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 Thu Nov 6 00:59:55 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 DCF873A69C6; Thu, 6 Nov 2008 00:59:55 -0800 (PST) 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 8424B3A6993 for ; Thu, 6 Nov 2008 00:59:54 -0800 (PST) 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 JBoJw+0q4DHn for ; Thu, 6 Nov 2008 00:59:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 9D42A3A682C for ; Thu, 6 Nov 2008 00:59:52 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA68xlwF028550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 09:59:47 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA68xYQb021591; Thu, 6 Nov 2008 09:59:46 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 09:59:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 09:54:27 +0100 Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C441AC6@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Should we just declare RUCUS dead and move on? (Orhavewealready?) Thread-Index: Ack/ZRjjHCPDIcsxS0iqGjkLUwr6RAAhE+kwAACrgZA= References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com><1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> <547F018265F92642B577B986577D671C441AC6@VENUS.office> From: "Charzinski, Joachim (NSN - DE/Munich)" To: "ext Saverio Niccolini" , "David Schwartz" , "Tschofenig, Hannes (NSN - FI/Espoo)" X-OriginalArrivalTime: 06 Nov 2008 08:59:33.0572 (UTC) FILETIME=[FCAC5040:01C93FED] Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Orhavewealready?) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Saverio wrote: = > ... = > they do not want to charter an experiment unless they > strongly believe is going to be successful > ... You probably hit the point here. The whole idea of an experiment = is to be open minded about the outcome. Sometimes this is hard = just because everybody wants their work to be successful. = I see the value of an EG exactly in the fact that it has a = significantly higher probability for "failing". If EGs are not = easier (and faster) to start and to stop than WGs, there is = no point in talking about EGs. Finding out after 6 months = that it is not necessary to start a WG would be a success for the EG concept. So I don't understand why the EG can't be = started. The tricky thing should not be starting the EG but = consequently acting upon the EG's results after a given time. Best regards Joachim. -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of e= xt Saverio Niccolini Sent: Thursday, November 06, 2008 9:35 AM To: David Schwartz; Tschofenig, Hannes (NSN - FI/Espoo) Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Orhave= wealready?) Having a formal EG/WG formed is definitely a good reason for us to spend time on it (as we have resources to do chartered work and not every work we like) and this is what we did so far trying collaborating to form the EG (spending enough time I think) But I also know that Cullen is doing his best to get this done, he just needs some more time to put the right things in place and finding the right people to lead this effort, remember that there is no EG charted so far (it is just an experiment IETF = started some time ago) and maybe IETF leaders are cautious on = this (they do not want to charter an experiment unless they strongly believe is going to be successful) Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Manager, Real-Time Communications Group 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 !!! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 = = > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > On Behalf Of David Schwartz > Sent: Wednesday, November 05, 2008 5:39 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: rucus BoF > Subject: Re: [Rucus] Should we just declare RUCUS dead and = > move on? (Or havewealready?) > = > Hi Dan, Hannes > = > I myself have been holding off pending some resolution. As it = > is I have a very hard time justifying time I spend on IETF = > related work. > = > I would love to see the EG or better yet a WG formed sooner = > rather than later. > = > Just my two cents, > = > D. > = > On Nov 5, 2008, at 6:12 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > = > > Hi Dan, > > > > you are right that the Exploratory Group (EG) does not seem to be a = > > workable concept for the IETF with the huge amount of overhead. > > > > From the BOF chair point of view the preparation for the EG is = > > finished some time ago. We submitted the charter with the = > request for = > > creating an EG to the ADs. I was obviously hoping that this = > could be = > > executed fast. > > I cannot create the group myself, as you know. > > > > Still doing the work regardless whether a BOF exists is certainly a = > > good idea. > > > > Ciao > > Hannes > > > > PS: I worked on a draft for the submission deadline but did = > not submit = > > since Henning and I believe it needs more work. > > > >> -----Original Message----- > >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On = > >> Behalf Of ext Dan York > >> Sent: 05 November, 2008 18:00 > >> To: rucus BoF > >> Subject: [Rucus] Should we just declare RUCUS dead and = > move on? (Or = > >> have wealready?) > >> > >> Folks, > >> > >> I notice that RUCUS is (understandably) yet again not on = > the agenda = > >> for IETF 73. It was also not on the agenda for IETF 72 and = > was last = > >> held at IETF 71 **8 months ago** in March in Philadelphia. = > At IETF = > >> 71, we talked about creating a > >> *6-month* Exploratory Group (EG) to explore some of the = > basic issues = > >> and decide whether or not we needed to move into a WG. > >> > >> That was to be a 6-month plan, but here we are 8 months = > later and we = > >> haven't started that 6-month window... > >> > >> Based on past email, it seems to me that we are waiting upon the = > >> "blessing" of the ADs to launch the EG before we begin the work. > >> Given how taxed for time the ADs appear to be, what is the = > likelihood = > >> for this to occur? Do we need to do something drastic like hide = > >> Cullen's MacBook Air at IETF 73 when he leaves it on a chair to go = > >> speak at the mic and refuse to give it back to him until = > he provides = > >> an answer? (Thus creating a rucus about RUCUS.) > >> > >> I'm joking on that point (as Cullen will now avoid being = > near me for = > >> all of IETF 73!), but I am serious that I think we need to = > figure out = > >> what we are doing with this list and group. > >> > >> If we want to move this body of work forward, can the = > RUCUS co-chairs > >> *please* find out from the ADs about RUCUS becoming an EG? > >> > >> Or should we just start working on I-D's and acting as if = > this IS a = > >> BOF/EG? (Do we all have time to do so?) > >> > >> Or if we think that the work we've talked about doing in RUCUS is = > >> simply too difficult to do or at least to do within the = > IETF, let's = > >> just shut down the list and move on. We all have a zillion other = > >> things to do. > >> > >> 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 > > > > = > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email = > Security System. > > For more information please visit http://www.messagelabs.com/email = > > = > ______________________________________________________________________ > = > _______________________________________________ > 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 ---------------------------------------------------------- Joachim Charzinski Nokia Siemens Networks Research, Technology and Platforms = Strategy & Vision / End-to-end Network Architecture Evolution = St.-Martin-Str. 53 Post box: D-80240 Muenchen D-81541 Muenchen Germany Tel: +49 89 636 79902 Joachim.Charzinski@nsn.com = http://www.nokiasiemensnetworks.com/global/ Think before you print Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens Net= works Management GmbH Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivin= en Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Nov 6 10:32:30 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 A669C3A69F5; Thu, 6 Nov 2008 10:32:30 -0800 (PST) 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 26A373A69F5 for ; Thu, 6 Nov 2008 10:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 D2rvjJSSXatX for ; Thu, 6 Nov 2008 10:32:28 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 1BE583A68F6 for ; Thu, 6 Nov 2008 10:32:28 -0800 (PST) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mA6IVgZ10352; Thu, 6 Nov 2008 18:31:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 12:28:11 -0600 Message-ID: In-Reply-To: <547F018265F92642B577B986577D671C441AC6@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) Thread-Index: Ack/ZRjjHCPDIcsxS0iqGjkLUwr6RAAhE+kwABTKx5A= References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> <1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> <547F018265F92642B577B986577D671C441AC6@VENUS.office> From: "Mary Barnes" To: "Saverio Niccolini" , "David Schwartz" , "Tschofenig, Hannes (NSN - FI/Espoo)" Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) 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 One important thing to consider (and I know this has been mentioned before) is that individuals are free to work together without having an official IETF group formed. MEDIACTRL is a really good example. Although I recognize that work was far easier to scope, it did involve a variety of vendors (and service providers interested in the solution) to work together. The informal design team met at IETF meetings for a couple years. It was quite small and made very good progress between meetings, as well, since the early work is often the most interesting. Personally, I do think it's worthwhile to explore this area and figure out if and which specific problems can be solved. I would suggest folks try to find a common time to get together (in Minneapolis ideally, although conference calls might work) and start discussing some of the items in the proposed EG charter and thus be better prepared to work towards the aggressive milestones if/when the EG is chartered. Mary. Note: I snipped the remainder of the thread... -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of Saverio Niccolini Sent: Thursday, November 06, 2008 2:35 AM To: David Schwartz; Tschofenig, Hannes (NSN - FI/Espoo) Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) Having a formal EG/WG formed is definitely a good reason for us to spend time on it (as we have resources to do chartered work and not every work we like) and this is what we did so far trying collaborating to form the EG (spending enough time I think) But I also know that Cullen is doing his best to get this done, he just needs some more time to put the right things in place and finding the right people to lead this effort, remember that there is no EG charted so far (it is just an experiment IETF started some time ago) and maybe IETF leaders are cautious on this (they do not want to charter an experiment unless they strongly believe is going to be successful) Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group 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 Nov 6 12:16: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 43A743A67E3; Thu, 6 Nov 2008 12:16:11 -0800 (PST) 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 3C8053A67E3 for ; Thu, 6 Nov 2008 12:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.414 X-Spam-Level: X-Spam-Status: No, score=-5.414 tagged_above=-999 required=5 tests=[AWL=1.185, 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 UKHzUBjkR9LZ for ; Thu, 6 Nov 2008 12:16:09 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C3BC63A67AC for ; Thu, 6 Nov 2008 12:16:08 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mA6KFGU0023436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2008 21:15:16 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mA6KFAjn016547; Thu, 6 Nov 2008 21:15:13 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 21:15:09 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 21:15:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 22:01:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) Thread-Index: Ack/ZRjjHCPDIcsxS0iqGjkLUwr6RAAhE+kwABTKx5AAAxgPsA== References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> <1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> <547F018265F92642B577B986577D671C441AC6@VENUS.office> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Mary Barnes" , "Saverio Niccolini" , "David Schwartz" X-OriginalArrivalTime: 06 Nov 2008 20:15:03.0604 (UTC) FILETIME=[5A746740:01C9404C] Cc: rucus BoF Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) 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 That's very true. Nobody prevents us from still doing some work, having phone conference calls, meet during the IETF#73 week, etc. Let's focus on the IETF meeting and see whether someone is interested to have a chat about the topic. To see who is actually interested in a discussion and when those folks arrive please put your name here: http://www.doodle.com/sevy8iih5udfuh94 Ciao Hannes >-----Original Message----- >From: ext Mary Barnes [mailto:mary.barnes@nortel.com] >Sent: 06 November, 2008 20:28 >To: Saverio Niccolini; David Schwartz; Tschofenig, Hannes (NSN >- FI/Espoo) >Cc: rucus BoF >Subject: RE: [Rucus] Should we just declare RUCUS dead and >move on? (Or havewealready?) > >One important thing to consider (and I know this has been mentioned >before) is that individuals are free to work together without >having an official IETF group formed. MEDIACTRL is a really >good example. Although I recognize that work was far easier to >scope, it did involve a variety of vendors (and service >providers interested in the solution) to work together. The >informal design team met at IETF meetings for a couple years. >It was quite small and made very good progress between >meetings, as well, since the early work is often the most interesting. > >Personally, I do think it's worthwhile to explore this area >and figure out if and which specific problems can be solved. > >I would suggest folks try to find a common time to get >together (in Minneapolis ideally, although conference calls >might work) and start discussing some of the items in the >proposed EG charter and thus be better prepared to work >towards the aggressive milestones if/when the EG is chartered. > >Mary. >Note: I snipped the remainder of the thread... > >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of Saverio Niccolini >Sent: Thursday, November 06, 2008 2:35 AM >To: David Schwartz; Tschofenig, Hannes (NSN - FI/Espoo) >Cc: rucus BoF >Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or >havewealready?) > >Having a formal EG/WG formed is definitely a good reason for >us to spend time on it (as we have resources to do chartered >work and not every work we like) and this is what we did so >far trying collaborating to form the EG (spending enough time I think) > >But I also know that Cullen is doing his best to get this >done, he just needs some more time to put the right things in >place and finding the right people to lead this effort, >remember that there is no EG charted so far (it is just an >experiment IETF started some time ago) and maybe IETF leaders >are cautious on this (they do not want to charter an >experiment unless they strongly believe is going to be successful) > >Saverio > >============================================================ >Dr. Saverio Niccolini >Manager, Real-Time Communications Group >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 Nov 6 12:22:26 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 B1A0A3A6950; Thu, 6 Nov 2008 12:22:26 -0800 (PST) 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 41EA63A67E3 for ; Thu, 6 Nov 2008 12:22:25 -0800 (PST) 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 9KfrEOtT9b8H for ; Thu, 6 Nov 2008 12:22:24 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id D588A3A67AC for ; Thu, 6 Nov 2008 12:22:23 -0800 (PST) Received: from [66.65.228.203] (account dyork HELO pc-00144.lodestar2.dyndns.org) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 36810986; Thu, 06 Nov 2008 20:21:39 +0000 Message-Id: <6DC62602-646E-455B-BDEE-4EA5E1DAA2EC@voxeo.com> From: Dan York To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 6 Nov 2008 15:21:36 -0500 References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> <1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net> <547F018265F92642B577B986577D671C441AC6@VENUS.office> X-Mailer: Apple Mail (2.929.2) Cc: rucus BoF , Saverio Niccolini Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or havewealready?) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, It's not clear to me what your survey is doing... are you trying to arrange a session BEFORE the meeting starts? i.e. on Saturday or Sunday? I arrive very late on Sunday and so there's no chance I can do much there. Why don't we look on gathering some evening or lunch during the week? Dan On Nov 6, 2008, at 3:01 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > That's very true. > > Nobody prevents us from still doing some work, having phone conference > calls, meet during the IETF#73 week, etc. > > Let's focus on the IETF meeting and see whether someone is > interested to > have a chat about the topic. To see who is actually interested in a > discussion and when those folks arrive please put your name here: > http://www.doodle.com/sevy8iih5udfuh94 > > Ciao > Hannes > >> -----Original Message----- >> From: ext Mary Barnes [mailto:mary.barnes@nortel.com] >> Sent: 06 November, 2008 20:28 >> To: Saverio Niccolini; David Schwartz; Tschofenig, Hannes (NSN >> - FI/Espoo) >> Cc: rucus BoF >> Subject: RE: [Rucus] Should we just declare RUCUS dead and >> move on? (Or havewealready?) >> >> One important thing to consider (and I know this has been mentioned >> before) is that individuals are free to work together without >> having an official IETF group formed. MEDIACTRL is a really >> good example. Although I recognize that work was far easier to >> scope, it did involve a variety of vendors (and service >> providers interested in the solution) to work together. The >> informal design team met at IETF meetings for a couple years. >> It was quite small and made very good progress between >> meetings, as well, since the early work is often the most >> interesting. >> >> Personally, I do think it's worthwhile to explore this area >> and figure out if and which specific problems can be solved. >> >> I would suggest folks try to find a common time to get >> together (in Minneapolis ideally, although conference calls >> might work) and start discussing some of the items in the >> proposed EG charter and thus be better prepared to work >> towards the aggressive milestones if/when the EG is chartered. >> >> Mary. >> Note: I snipped the remainder of the thread... >> >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Saverio Niccolini >> Sent: Thursday, November 06, 2008 2:35 AM >> To: David Schwartz; Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: rucus BoF >> Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? >> (Or >> havewealready?) >> >> Having a formal EG/WG formed is definitely a good reason for >> us to spend time on it (as we have resources to do chartered >> work and not every work we like) and this is what we did so >> far trying collaborating to form the EG (spending enough time I >> think) >> >> But I also know that Cullen is doing his best to get this >> done, he just needs some more time to put the right things in >> place and finding the right people to lead this effort, >> remember that there is no EG charted so far (it is just an >> experiment IETF started some time ago) and maybe IETF leaders >> are cautious on this (they do not want to charter an >> experiment unless they strongly believe is going to be successful) >> >> Saverio >> >> ============================================================ >> Dr. Saverio Niccolini >> Manager, Real-Time Communications Group >> 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 -- 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 Thu Nov 6 12:26:48 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 978BE3A6A33; Thu, 6 Nov 2008 12:26:48 -0800 (PST) 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 E91B53A699F for ; Thu, 6 Nov 2008 12:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 H6CCxt0NeudG for ; Thu, 6 Nov 2008 12:26:45 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4BB583A696C for ; Thu, 6 Nov 2008 12:26:45 -0800 (PST) Received: (qmail invoked by alias); 06 Nov 2008 20:26:11 -0000 Received: from a91-154-101-110.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.101.110] by mail.gmx.net (mp008) with SMTP; 06 Nov 2008 21:26:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19jL9lwXnZjewFLIo5Y7f3BnW1g50WIUQln/9Y66A gvj+c6Iz7yGCX/ From: "Hannes Tschofenig" To: "'Dan York'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com><1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net><547F018265F92642B577B986577D671C441AC6@VENUS.office> <6DC62602-646E-455B-BDEE-4EA5E1DAA2EC@voxeo.com> Date: Thu, 6 Nov 2008 22:26:10 +0200 Message-ID: <079601c9404d$e8c93650$d206d00a@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6DC62602-646E-455B-BDEE-4EA5E1DAA2EC@voxeo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AclATWIkmq52J3TpQamIPWrVDgviaQAAFsCw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: 'rucus BoF' , 'Saverio Niccolini' Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Orhavewealready?) 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 was hoping that some folks arrive already earlier. On Saturday and Sunday folks are a bit more relaxed and we have more time. The week is already pretty much full for most people already -- specifically the lunch time and evenings. Ciao Hannes >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of Dan York >Sent: 06 November, 2008 22:22 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: rucus BoF; Saverio Niccolini >Subject: Re: [Rucus] Should we just declare RUCUS dead and >move on? (Orhavewealready?) > >Hannes, > >It's not clear to me what your survey is doing... are you >trying to arrange a session BEFORE the meeting starts? i.e. on >Saturday or Sunday? > >I arrive very late on Sunday and so there's no chance I can do >much there. > >Why don't we look on gathering some evening or lunch during the week? > >Dan > >On Nov 6, 2008, at 3:01 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> That's very true. >> >> Nobody prevents us from still doing some work, having phone >conference >> calls, meet during the IETF#73 week, etc. >> >> Let's focus on the IETF meeting and see whether someone is >interested >> to have a chat about the topic. To see who is actually >interested in a >> discussion and when those folks arrive please put your name here: >> http://www.doodle.com/sevy8iih5udfuh94 >> >> Ciao >> Hannes >> >>> -----Original Message----- >>> From: ext Mary Barnes [mailto:mary.barnes@nortel.com] >>> Sent: 06 November, 2008 20:28 >>> To: Saverio Niccolini; David Schwartz; Tschofenig, Hannes (NSN >>> - FI/Espoo) >>> Cc: rucus BoF >>> Subject: RE: [Rucus] Should we just declare RUCUS dead and move on? >>> (Or havewealready?) >>> >>> One important thing to consider (and I know this has been mentioned >>> before) is that individuals are free to work together >without having >>> an official IETF group formed. MEDIACTRL is a really good example. >>> Although I recognize that work was far easier to scope, it did >>> involve a variety of vendors (and service providers >interested in the >>> solution) to work together. The informal design team met at IETF >>> meetings for a couple years. >>> It was quite small and made very good progress between meetings, as >>> well, since the early work is often the most interesting. >>> >>> Personally, I do think it's worthwhile to explore this area and >>> figure out if and which specific problems can be solved. >>> >>> I would suggest folks try to find a common time to get together (in >>> Minneapolis ideally, although conference calls might work) >and start >>> discussing some of the items in the proposed EG charter and thus be >>> better prepared to work towards the aggressive milestones >if/when the >>> EG is chartered. >>> >>> Mary. >>> Note: I snipped the remainder of the thread... >>> >>> -----Original Message----- >>> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On >>> Behalf Of Saverio Niccolini >>> Sent: Thursday, November 06, 2008 2:35 AM >>> To: David Schwartz; Tschofenig, Hannes (NSN - FI/Espoo) >>> Cc: rucus BoF >>> Subject: Re: [Rucus] Should we just declare RUCUS dead and >move on? >>> (Or >>> havewealready?) >>> >>> Having a formal EG/WG formed is definitely a good reason for us to >>> spend time on it (as we have resources to do chartered work and not >>> every work we like) and this is what we did so far trying >>> collaborating to form the EG (spending enough time I >>> think) >>> >>> But I also know that Cullen is doing his best to get this done, he >>> just needs some more time to put the right things in place and >>> finding the right people to lead this effort, remember that >there is >>> no EG charted so far (it is just an experiment IETF started >some time >>> ago) and maybe IETF leaders are cautious on this (they do >not want to >>> charter an experiment unless they strongly believe is going to be >>> successful) >>> >>> Saverio >>> >>> ============================================================ >>> Dr. Saverio Niccolini >>> Manager, Real-Time Communications Group >>> 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 > >-- >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 Sun Nov 9 22:50:27 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 CD9833A68FC; Sun, 9 Nov 2008 22:50:27 -0800 (PST) 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 270CE3A684B for ; Sun, 9 Nov 2008 22:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_05=-1.11] 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 h68uIlpxgnd8 for ; Sun, 9 Nov 2008 22:50:26 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AF1013A68FC for ; Sun, 9 Nov 2008 22:50:25 -0800 (PST) Received: (qmail invoked by alias); 10 Nov 2008 06:50:21 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp067) with SMTP; 10 Nov 2008 07:50:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181QoREMBs1op4AR9rCMwVeI5niT72HOGL0jci37s 5u4AiKk0Ofuu/t From: "Hannes Tschofenig" To: "'rucus BoF'" References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com><1E4F04B2-9F6F-4466-86F5-1B685D94F700@xconnect.net><547F018265F92642B577B986577D671C441AC6@VENUS.office> Date: Mon, 10 Nov 2008 08:50:21 +0200 Message-ID: <00a301c94300$9a416dd0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ack/ZRjjHCPDIcsxS0iqGjkLUwr6RAAhE+kwABTKx5AAAxgPsACt1xZA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Rucus] RUCUS Face-to-Face Meeting @ IETF#73 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 Please indicate your preference whether you would like to get together at IETF#73 for a chat about RUCUS: http://www.doodle.com/sevy8iih5udfuh94 You have three choices for a meeting: * Saturday * Sunday * some time during the week (=other) If most folks prefer to have a chat during the week then I will arrange something with the folks who have put their name on that list. So, please indicate your preference as soon as possible. Ciao Hannes _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Nov 11 01:45: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 328073A6AFF; Tue, 11 Nov 2008 01:45:00 -0800 (PST) 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 9254E3A6AFF for ; Tue, 11 Nov 2008 01:44:59 -0800 (PST) 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 Z5cUrisdjIBR for ; Tue, 11 Nov 2008 01:44:58 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BF1343A6A7D for ; Tue, 11 Nov 2008 01:44:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4E56E2C000359; Tue, 11 Nov 2008 10:44:56 +0100 (CET) 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 jTqt+O6HnjGe; Tue, 11 Nov 2008 10:44:56 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 2C32C2C000305; Tue, 11 Nov 2008 10:44:46 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Nov 2008 10:44:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Interim Meeting in Malta Thread-Index: Ack7SvREUR93qHMqTLG77P7B/CX+rAIebszg References: From: "Jan Seedorf" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Subject: Re: [Rucus] Interim Meeting in Malta 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, all, Sorry for the late reply on this: I would be available for a RUCUS interim meeting in Malta. But for now let us see if we can have a RUCUS meeting in Minneapolis next week, that would be good. I have filled out the doodle and will be there all week (including the weekend before). Kind regards, Jan > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Friday, October 31, 2008 12:22 PM > To: rucus@ietf.org > Subject: [Rucus] Interim Meeting in Malta > > Saverio suggested to use the interim meeting in Malta to > discuss RUCUS. > This is an interesting idea. > > Who would be willing to show up there? > > Ciao > Hannes > > PS: The request for creating an EG is with Cullen and Jon. > Hope to hear some positive news soon. > _______________________________________________ > 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 Tue Nov 11 03:50:19 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 2C3683A6B08; Tue, 11 Nov 2008 03:50:19 -0800 (PST) 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 631EA28B797 for ; Tue, 11 Nov 2008 03:50:17 -0800 (PST) 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 g4szGWqfBLQu for ; Tue, 11 Nov 2008 03:50:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 183B23A69CD for ; Tue, 11 Nov 2008 03:50:15 -0800 (PST) Received: (qmail invoked by alias); 11 Nov 2008 11:50:14 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp006) with SMTP; 11 Nov 2008 12:50:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/y47h6TQjya7Ze4yT+u5/GFF9MjsewN29Lp2S5Im TfGjFctjbpxecf From: "Hannes Tschofenig" To: "'Jan Seedorf'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , References: Date: Tue, 11 Nov 2008 13:50:09 +0200 Message-ID: <00c801c943f3$a8f65680$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: Ack7SvREUR93qHMqTLG77P7B/CX+rAIebszgAAuc0SA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Subject: Re: [Rucus] Interim Meeting in Malta 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 So far, I got very few responses to my question about having an interim meeting in Malta. Hence, I will not ask for a slot. But let's meet at IETF#73 since there was some interest expressed at http://www.doodle.com/sevy8iih5udfuh94 Ciao Hannes >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of Jan Seedorf >Sent: 11 November, 2008 11:45 >To: Tschofenig, Hannes (NSN - FI/Espoo); rucus@ietf.org >Subject: Re: [Rucus] Interim Meeting in Malta > >Dear Hannes, all, > >Sorry for the late reply on this: I would be available for a >RUCUS interim meeting in Malta. But for now let us see if we >can have a RUCUS meeting in Minneapolis next week, that would >be good. I have filled out the doodle and will be there all >week (including the weekend before). > >Kind regards, >Jan > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf >> Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: Friday, October 31, 2008 12:22 PM >> To: rucus@ietf.org >> Subject: [Rucus] Interim Meeting in Malta >> >> Saverio suggested to use the interim meeting in Malta to discuss >> RUCUS. >> This is an interesting idea. >> >> Who would be willing to show up there? >> >> Ciao >> Hannes >> >> PS: The request for creating an EG is with Cullen and Jon. >> Hope to hear some positive news soon. >> _______________________________________________ >> 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 > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Nov 13 10:57:09 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 E6DB43A69CF; Thu, 13 Nov 2008 10:57:09 -0800 (PST) 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 F22C33A69CF for ; Thu, 13 Nov 2008 10:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=-1.372, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] 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 dJYU7Lhg8vAM for ; Thu, 13 Nov 2008 10:57:07 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7713F3A69CC for ; Thu, 13 Nov 2008 10:57:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mADIv3Ym007293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Nov 2008 19:57:03 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mADIv0IR015434 for ; Thu, 13 Nov 2008 19:57:03 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 19:57:02 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 19:57:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Nov 2008 20:52:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RUCUS F2F @ IETF#73 Thread-Index: AclFwQcwj3k7UtmsRsKsTj8dkFSNYA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 13 Nov 2008 18:57:01.0479 (UTC) FILETIME=[9C951370:01C945C1] Subject: [Rucus] RUCUS F2F @ IETF#73 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 A few of us are going to meet next Monday, during lunch time (1130-1300), to chat about the next steps in RUCUS. The meeting room still needs to be determined. Ciao Hannes _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Nov 15 16:20:27 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 699153A68E8; Sat, 15 Nov 2008 16:20:27 -0800 (PST) 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 3BCA83A6883 for ; Sat, 15 Nov 2008 16:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 CP8g9WaeJhxk for ; Sat, 15 Nov 2008 16:20:25 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 212E33A67B6 for ; Sat, 15 Nov 2008 16:20:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,612,1220227200"; d="scan'208";a="195517598" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Nov 2008 00:20:25 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mAG0KPsd020963 for ; Sat, 15 Nov 2008 16:20:25 -0800 Received: from [172.28.172.158] (sjc-vpn7-443.cisco.com [10.21.145.187]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAG0KNYE006652 for ; Sun, 16 Nov 2008 00:20:24 GMT Message-Id: <39E8251D-3DBE-4C89-B48D-99AC01C7CE36@cisco.com> From: Cullen Jennings To: rucus BoF In-Reply-To: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 13:42:41 -0700 References: <94BC603E-A430-4A6A-97E7-E4441B5E4EF0@voxeo.com> X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3526; t=1226794825; x=1227658825; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Rucus]=20Should=20we=20just=20declare= 20RUCUS=20dead=20and=20move=20on?=20(Or=20have=20we=20alread y?) |Sender:=20; bh=Ira7T2NRV9t7yLwXB5Pt83QK0aDKm0hwLO0JIXlgA8o=; b=fj2+jTzjfV65dpTPwtPAsADafcP0BrXGiQm3A5YZ+LoDWz2af69e+GlRDZ oTX0gA2V6ITp6C02fSiaNMsVzLeUvmCF+9cUzC/3DJBgFoV3jkaHSy9WKaVR O8FgzpvmHK; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Rucus] Should we just declare RUCUS dead and move on? (Or have we already?) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Just as a status update ... so far everyone Jon and I have asked to chair this EG had declined. As usual we would like to have a less one chair with lots of energy and one experienced chair that is capable of making sure any "strong personalities, ADs, etc" don't take things an inappropriate direction. There are still some folks we are pursuing as chair candidates but most people want to think about for awhile before saying No. Work is being done but the commitment to actually doing work in this EG seems low. We have yet to see the drafts that were going to be produced before the Dublin meeting that covered the proposal that came out of the BOF. On Nov 5, 2008, at 8:59 , Dan York wrote: > Folks, > > I notice that RUCUS is (understandably) yet again not on the agenda > for IETF 73. It was also not on the agenda for IETF 72 and was last > held at IETF 71 **8 months ago** in March in Philadelphia. At IETF > 71, we talked about creating a *6-month* Exploratory Group (EG) to > explore some of the basic issues and decide whether or not we needed > to move into a WG. > > That was to be a 6-month plan, but here we are 8 months later and we > haven't started that 6-month window... > > Based on past email, it seems to me that we are waiting upon the > "blessing" of the ADs to launch the EG before we begin the work. At the end of the BOF, I thought work was going to start right away on a draft and that would be submitted before Dublin. I don't think that the anyone should be waiting for the ADs to do something before doing individual drafts that are in the scope of current proposed charter. > Given how taxed for time the ADs appear to be, what is the > likelihood for this to occur? Do we need to do something drastic > like hide Cullen's MacBook Air at IETF 73 when he leaves it on a > chair to go speak at the mic and refuse to give it back to him until > he provides an answer? (Thus creating a rucus about RUCUS.) > > I'm joking on that point (as Cullen will now avoid being near me for > all of IETF 73!), but I am serious that I think we need to figure > out what we are doing with this list and group. I'm bringing a backup air to Dublin :-) > > > If we want to move this body of work forward, can the RUCUS co- > chairs *please* find out from the ADs about RUCUS becoming an EG? I thought most of this had been sent on to them but definitely, catch me in a hallway at IETF 73. I will be at the welcome reception Sunday which is a tradition place to beat up^H^H^H^H^H find, ADs. > > > Or should we just start working on I-D's and acting as if this IS a > BOF/EG? (Do we all have time to do so?) > > Or if we think that the work we've talked about doing in RUCUS is > simply too difficult to do or at least to do within the IETF, let's > just shut down the list and move on. We all have a zillion other > things to do. > > 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 Sun Nov 16 11:24: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 E1FF13A6918; Sun, 16 Nov 2008 11:24:18 -0800 (PST) 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 721E83A6918 for ; Sun, 16 Nov 2008 11:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_20=-0.74] 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 AM4E0Sw9iu-O for ; Sun, 16 Nov 2008 11:24:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DD3D93A6358 for ; Sun, 16 Nov 2008 11:24:15 -0800 (PST) Received: (qmail invoked by alias); 16 Nov 2008 19:24:13 -0000 Received: from unknown (EHLO 4FIL42860) [130.129.31.217] by mail.gmx.net (mp028) with SMTP; 16 Nov 2008 20:24:13 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XrFlOoAQXBNuA9chkLVRodur1jgHf5nsUAV9ZsM 7rtFaqciyiODN9 From: "Hannes Tschofenig" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , References: Date: Sun, 16 Nov 2008 21:24:01 +0200 Message-ID: <000201c94820$e480a800$17ac1cac@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclFwQcwj3k7UtmsRsKsTj8dkFSNYACXxq6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Subject: [Rucus] Meeting Room for RUCUS F2F @ IETF#73 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 The room # is 2136. Ciao Hannes >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 13 November, 2008 20:53 >To: rucus@ietf.org >Subject: [Rucus] RUCUS F2F @ IETF#73 > >A few of us are going to meet next Monday, during lunch time >(1130-1300), to chat about the next steps in RUCUS. > >The meeting room still needs to be determined. > >Ciao >Hannes > >_______________________________________________ >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 Nov 17 09:03:27 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 8B00428C1A9; Mon, 17 Nov 2008 09:03:27 -0800 (PST) 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 8DF9A3A67A6 for ; Mon, 17 Nov 2008 09:03:25 -0800 (PST) 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 EevktnrjMWiF for ; Mon, 17 Nov 2008 09:03:24 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1DE7A3A6A22 for ; Mon, 17 Nov 2008 09:02:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 529B92C0012C2; Mon, 17 Nov 2008 18:02:49 +0100 (CET) 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 DLUQfo22w6A6; Mon, 17 Nov 2008 18:02:49 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 31CAA2C0008DF; Mon, 17 Nov 2008 18:02:34 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 18:02:23 +0100 Message-ID: In-Reply-To: <000201c94820$e480a800$17ac1cac@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Meeting Room for RUCUS F2F @ IETF#73 Thread-Index: AclFwQcwj3k7UtmsRsKsTj8dkFSNYACXxq6AAC2GBqA= References: <000201c94820$e480a800$17ac1cac@nsnintra.net> From: "Jan Seedorf" To: "Hannes Tschofenig" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Subject: Re: [Rucus] Meeting Room for RUCUS F2F @ IETF#73 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 Hannes, Where is this room? - Jan -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Sunday, November 16, 2008 8:24 PM To: Tschofenig, Hannes (NSN - FI/Espoo); rucus@ietf.org Subject: [Rucus] Meeting Room for RUCUS F2F @ IETF#73 The room # is 2136. Ciao Hannes >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of ext Tschofenig, Hannes (NSN - FI/Espoo) >Sent: 13 November, 2008 20:53 >To: rucus@ietf.org >Subject: [Rucus] RUCUS F2F @ IETF#73 > >A few of us are going to meet next Monday, during lunch time >(1130-1300), to chat about the next steps in RUCUS. > >The meeting room still needs to be determined. > >Ciao >Hannes > >_______________________________________________ >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 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Nov 17 10:59:47 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 620F43A696D; Mon, 17 Nov 2008 10:59:47 -0800 (PST) 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 F03403A696D for ; Mon, 17 Nov 2008 10:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.884 X-Spam-Level: X-Spam-Status: No, score=-4.884 tagged_above=-999 required=5 tests=[AWL=1.715, 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 UxTOQa1HLABg for ; Mon, 17 Nov 2008 10:59:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8D6D73A689E for ; Mon, 17 Nov 2008 10:59:44 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAHIxggN012434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Nov 2008 19:59:42 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAHIxgHn003227 for ; Mon, 17 Nov 2008 19:59:42 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 19:59:23 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 19:59:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 20:59:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes from F2F at IETF#73 Thread-Index: AclIo3QAROiAkuBcQ6itNYV4difynw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Nov 2008 18:59:23.0246 (UTC) FILETIME=[9ABC00E0:01C948E6] Subject: [Rucus] Meeting Minutes from F2F at IETF#73 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 Meeting Minutes =============== Participants: - Hannes Tschofenig - Mary Barnes - David Schwartz - Roger Marshall - Kai Fischer - Jan Seedorf - Keith Drage - Juergen Quitteck - Thomas Froment - Hendrik Scholz - Jiri Kuthan - Victor Pascual - Salvatore Loreto - Raphael Coeffic Meeting Minutes: Hannes Tschofenig Hannes gives a short introduction of the history of the RUCUS EG. Dan: Proposal for forming an EG took longer and requires folks to write short documents. Are we heading along the right path? Why didn't we got something done? Juergen: We have written drafts already. I have problems understandign the intention of the IESG. I don't see on the path they are willing to set us. Keith: Why do you want to know? Media CTRL did not exist as a WG for a long time and the group met at every IETF meeting. Juergen: What is the policy applied here? Dan: Step back to IETF#71 there was a lot of discussion and a lot of push-back on providing differnet solutions. Keith: You still don't know which direction you would like to go. Mary: They are not going to give us directions. This group should put together some building blocks together. Dan: The way forward was to create smaller, more generic building blocks David: What is a success or a failure of an EG? Keith: You still need someone to chair the group. Dan: Who is writing the drafts? David: There are drafts already. We should be re-using what is already out there. Dan: Look at the proposed charter and what it wants from the small drafts. The existing drafts don't discuss the 4 points. David: Individual building blocks work in isolation. Dan: Should we go back to the ADs and ask them for a different approach? David: Where does the problem come in? Which part of the end-to-end chain do we need to investigate? One problem at the edge, one problem at the interworking points, etc. Keith: The EG does not help you solving the scope problems. David: The problem is only at the edge, Hadriel says. I don't think that this is correct. SMS is a fascinating use case. Going to the spam score: where is it used? Dan: RFC 5149 provided potential solutions. It gives you the overall problem statement but what are the specific solutions that have to be put into an architecture. David: We need to bring the solutions down to earth. RFC 5149 should be used heavily but it misses the architecture. It misses the context. Thomas: The charter does not provide the architecture. Every document needs to capture it. David: The use cases are so different: IMS, VoIP, SMS We are not scoping it. Dan: How do we move the discussion forward? I hear that we need a framework or a scope. Hendrik: Summarizes the SPIT attack in Germany. Nobody knows what SPIT is going to look like. We would like to get some feedback messages for the users towards the operator. David: You are describing solutions for unwanted calls. Without looking at where the problems came from is quite easy. Raphael: The problem is always moving as adversaries use different attack mechanisms. You need a lot of building blocks for different categories. Jan: The phones were directly attack. David: This is very good input. We need these "problem vectors". Dan: We could look at them as one action items. Jan: Well. The solution on how to provide feedback would have helped. Dan: We shouldn't discuss these solutions. What actions should we take? David: It would be helpful to document about what is happening on email spam. Dan: David is going to write a document about email spam. Hannes should write something about XMPP spam. David can you write something about the XConnect experience. Juergen: We are maintaing an incident list since years. We can write up a few of them. We could put the list into a draft and ask folks to write up the details. Many of the cases are "mixed cases". Jan: We need to be careful to scope it too much on the current Spam attacks. An attacker would change David: Spam is about economics and it takes some time to change the economics. Dan: Your point is taken. Right now we don't have a lot of input and we should put them on paper. Do folks be willing to look at other communities? David, can you work with the email folks? Hannes, can you work on XMPP spam? Hannes: Yes, I will talk with Peter. David: Yes. Dan: Spam is a perception issue. Spam for you might not be spam for me. Dan Wing: Email has evolved from open relays to DKIM and with SIP we are still at the early days of email. The email community has figured out ways to overcome the problems of SBCs and to get identity to work. David: The fear of SBCs has slowed things down. Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT area. Dan: It would be useful to have a document. Hannes, Jan, Dan York, Dan Wing: Discussion about the differences between DKIM and SIP Identity. David: You have been silent, Jiri. Jiri: SIP Identity has a too strong identity signature mechanism. We do re-write the SDP to deal with NATs but we have a classical SIP Proxy deployment. Dan: Jan, can you write a document about the differences between DKIM and SIP Identity? Jan: Would do it when some folks in this room help me with it. Dan Wing: What is the target audience? Dan: The folks in the RUCUS group. _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Nov 17 11:08:21 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 879983A68A2; Mon, 17 Nov 2008 11:08:21 -0800 (PST) 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 A502B3A68A2 for ; Mon, 17 Nov 2008 11:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] 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 Bp84sLveIo8P for ; Mon, 17 Nov 2008 11:08:19 -0800 (PST) Received: from xconnect.net (host81-149-118-212.in-addr.btopenworld.com [81.149.118.212]) by core3.amsl.com (Postfix) with ESMTP id 5508A3A689E for ; Mon, 17 Nov 2008 11:08:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 19:06:44 -0000 Message-ID: <062B8EE81F2EC945A577C3EFAE1DD68E99629B@mail.xconnect.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting Minutes from F2F at IETF#73 Thread-Index: AclIo3QAROiAkuBcQ6itNYV4difynwARC2is References: From: "David Schwartz" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 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: multipart/mixed; boundary="===============0455054384==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a multi-part message in MIME format. --===============0455054384== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C948E7.D5E2841B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C948E7.D5E2841B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Small correction. RFC is 5039 not 5149 :) -----Original Message----- From: rucus-bounces@ietf.org on behalf of Tschofenig, Hannes (NSN - = FI/Espoo) Sent: Mon 11/17/2008 6:59 PM To: rucus@ietf.org Subject: [Rucus] Meeting Minutes from F2F at IETF#73 =20 Meeting Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Participants: - Hannes Tschofenig - Mary Barnes=20 - David Schwartz - Roger Marshall - Kai Fischer=20 - Jan Seedorf - Keith Drage - Juergen Quitteck - Thomas Froment - Hendrik Scholz - Jiri Kuthan - Victor Pascual - Salvatore Loreto - Raphael Coeffic Meeting Minutes: Hannes Tschofenig=20 Hannes gives a short introduction of the history of the RUCUS EG.=20 Dan: Proposal for forming an EG took longer and requires folks to write short documents.=20 Are we heading along the right path? Why didn't we got something done?=20 Juergen: We have written drafts already. I have problems understandign the intention of the IESG.=20 I don't see on the path they are willing to set us.=20 Keith: Why do you want to know?=20 Media CTRL did not exist as a WG for a long time and the group met at every IETF meeting.=20 Juergen: What is the policy applied here?=20 Dan: Step back to IETF#71 there was a lot of discussion and a lot of push-back on providing differnet solutions.=20 Keith: You still don't know which direction you would like to go.=20 Mary: They are not going to give us directions. This group should put together some building blocks together.=20 Dan: The way forward was to create smaller, more generic building blocks David: What is a success or a failure of an EG?=20 Keith: You still need someone to chair the group.=20 Dan: Who is writing the drafts?=20 David: There are drafts already.=20 We should be re-using what is already out there.=20 Dan: Look at the proposed charter and what it wants from the small drafts.=20 The existing drafts don't discuss the 4 points.=20 David: Individual building blocks work in isolation.=20 Dan: Should we go back to the ADs and ask them for a different approach? David: Where does the problem come in? Which part of the end-to-end chain do we need to investigate?=20 One problem at the edge, one problem at the interworking points, etc.=20 Keith: The EG does not help you solving the scope problems.=20 David: The problem is only at the edge, Hadriel says.=20 I don't think that this is correct.=20 SMS is a fascinating use case.=20 Going to the spam score: where is it used?=20 Dan: RFC 5149 provided potential solutions. It gives you the overall problem statement but what are the specific solutions that have to be put into an architecture. David: We need to bring the solutions down to earth.=20 RFC 5149 should be used heavily but it misses the architecture. It misses the context.=20 Thomas: The charter does not provide the architecture. Every document needs to capture it.=20 David: The use cases are so different: IMS, VoIP, SMS We are not scoping it. Dan: How do we move the discussion forward?=20 I hear that we need a framework or a scope.=20 Hendrik: Summarizes the SPIT attack in Germany. Nobody knows what SPIT is going to look like. We would like to get some feedback messages for the users towards the operator.=20 David: You are describing solutions for unwanted calls. Without looking at where the problems came from is quite easy.=20 Raphael: The problem is always moving as adversaries use different attack mechanisms. You need a lot of building blocks for different categories.=20 Jan: The phones were directly attack.=20 David: This is very good input. We need these "problem vectors".=20 Dan: We could look at them as one action items.=20 Jan: Well. The solution on how to provide feedback would have helped.=20 Dan: We shouldn't discuss these solutions.=20 What actions should we take?=20 David: It would be helpful to document about what is happening on email spam.=20 Dan: David is going to write a document about email spam. Hannes should write something about XMPP spam.=20 David can you write something about the XConnect experience.=20 Juergen: We are maintaing an incident list since years. We can write up a few of them.=20 We could put the list into a draft and ask folks to write up the details.=20 Many of the cases are "mixed cases".=20 Jan: We need to be careful to scope it too much on the current Spam attacks. An attacker would change David: Spam is about economics and it takes some time to change the economics.=20 Dan: Your point is taken. Right now we don't have a lot of input and we should put them on paper.=20 Do folks be willing to look at other communities? David, can you work with the email folks? Hannes, can you work on XMPP spam?=20 Hannes: Yes, I will talk with Peter.=20 David: Yes.=20 Dan: Spam is a perception issue. Spam for you might not be spam for me.=20 Dan Wing: Email has evolved from open relays to DKIM and with SIP we are still at the early days of email.=20 The email community has figured out ways to overcome the problems of SBCs and to get identity to work.=20 David: The fear of SBCs has slowed things down.=20 Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT area.=20 Dan: It would be useful to have a document. =20 Hannes, Jan, Dan York, Dan Wing: Discussion about the differences between DKIM and SIP Identity.=20 David: You have been silent, Jiri.=20 Jiri: SIP Identity has a too strong identity signature mechanism.=20 We do re-write the SDP to deal with NATs but we have a classical SIP Proxy deployment.=20 Dan: Jan, can you write a document about the differences between DKIM and SIP Identity?=20 Jan: Would do it when some folks in this room help me with it.=20 Dan Wing: What is the target audience?=20 Dan: The folks in the RUCUS group.=20 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ------_=_NextPart_001_01C948E7.D5E2841B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Rucus] Meeting Minutes from F2F at IETF#73

Small correction.

RFC is 5039 not 5149

:)


-----Original Message-----
From: rucus-bounces@ietf.org on behalf of Tschofenig, Hannes (NSN - = FI/Espoo)
Sent: Mon 11/17/2008 6:59 PM
To: rucus@ietf.org
Subject: [Rucus] Meeting Minutes from F2F at IETF#73

Meeting Minutes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Participants:

- Hannes Tschofenig
- Mary Barnes
- David Schwartz
- Roger Marshall
- Kai Fischer
- Jan Seedorf
- Keith Drage
- Juergen Quitteck
- Thomas Froment
- Hendrik Scholz
- Jiri Kuthan
- Victor Pascual
- Salvatore Loreto
- Raphael Coeffic

Meeting Minutes: Hannes Tschofenig

Hannes gives a short introduction of the history of the RUCUS EG.

Dan: Proposal for forming an EG took longer and requires folks to = write
short documents.

Are we heading along the right path? Why didn't we got something = done?

Juergen: We have written drafts already. I have problems = understandign
the intention of the IESG.
I don't see on the path they are willing to set us.

Keith: Why do you want to know?
Media CTRL did not exist as a WG for a long time and the group met = at
every IETF meeting.

Juergen: What is the policy applied here?

Dan: Step back to IETF#71 there was a lot of discussion and a lot of
push-back on providing differnet solutions.

Keith: You still don't know which direction you would like to go.

Mary: They are not going to give us directions. This group should = put
together some building blocks together.

Dan: The way forward was to create smaller, more generic building = blocks


David: What is a success or a failure of an EG?

Keith: You still need someone to chair the group.

Dan: Who is writing the drafts?

David: There are drafts already.
We should be re-using what is already out there.

Dan: Look at the proposed charter and what it wants from the small
drafts.
The existing drafts don't discuss the 4 points.

David: Individual building blocks work in isolation.

Dan: Should we go back to the ADs and ask them for a different = approach?


David: Where does the problem come in? Which part of the end-to-end
chain do we need to investigate?
One problem at the edge, one problem at the interworking points, = etc.

Keith: The EG does not help you solving the scope problems.

David: The problem is only at the edge, Hadriel says.
I don't think that this is correct.
SMS is a fascinating use case.
Going to the spam score: where is it used?

Dan: RFC 5149 provided potential solutions. It gives you the overall
problem statement but what are the specific solutions that have to = be
put into an architecture.

David: We need to bring the solutions down to earth.
RFC 5149 should be used heavily but it misses the architecture. It
misses the context.

Thomas: The charter does not provide the architecture. Every = document
needs to capture it.

David: The use cases are so different: IMS, VoIP, SMS
We are not scoping it.

Dan: How do we move the discussion forward?
I hear that we need a framework or a scope.

Hendrik: Summarizes the SPIT attack in Germany.
Nobody knows what SPIT is going to look like. We would like to get = some
feedback messages for the users towards the operator.

David: You are describing solutions for unwanted calls.
Without looking at where the problems came from is quite easy.

Raphael: The problem is always moving as adversaries use different
attack mechanisms. You need a lot of building blocks for different
categories.

Jan: The phones were directly attack.

David: This is very good input. We need these "problem = vectors".

Dan: We could look at them as one action items.

Jan: Well. The solution on how to provide feedback would have = helped.

Dan: We shouldn't discuss these solutions.
What actions should we take?

David: It would be helpful to document about what is happening on = email
spam.

Dan: David is going to write a document about email spam. Hannes = should
write something about XMPP spam.
David can you write something about the XConnect experience.

Juergen: We are maintaing an incident list since years. We can write = up
a few of them.
We could put the list into a draft and ask folks to write up the
details.
Many of the cases are "mixed cases".

Jan: We need to be careful to scope it too much on the current Spam
attacks. An attacker would change

David: Spam is about economics and it takes some time to change the
economics.

Dan: Your point is taken. Right now we don't have a lot of input and = we
should put them on paper.
Do folks be willing to look at other communities? David, can you = work
with the email folks? Hannes, can you work on XMPP spam?

Hannes: Yes, I will talk with Peter.

David: Yes.

Dan: Spam is a perception issue. Spam for you might not be spam for = me.

Dan Wing: Email has evolved from open relays to DKIM and with SIP we = are
still at the early days of email.
The email community has figured out ways to overcome the problems of
SBCs and to get identity to work.

David: The fear of SBCs has slowed things down.

Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT
area.

Dan: It would be useful to have a document. 

Hannes, Jan, Dan York, Dan Wing: Discussion about the differences
between DKIM and SIP Identity.

David: You have been silent, Jiri.

Jiri: SIP Identity has a too strong identity signature mechanism.
We do re-write the SDP to deal with NATs but we have a classical SIP
Proxy deployment.

Dan: Jan, can you write a document about the differences between = DKIM
and SIP Identity?

Jan: Would do it when some folks in this room help me with it.

Dan Wing: What is the target audience?

Dan: The folks in the RUCUS group.

_______________________________________________
Rucus mailing list
Rucus@ietf.org
https://www.ietf.org= /mailman/listinfo/rucus

______________________________________________________________________ This email has been scanned by the MessageLabs Email Security = System.
For more information please visit http://www.messagelabs.com/emai= l
______________________________________________________________________

------_=_NextPart_001_01C948E7.D5E2841B-- --===============0455054384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus --===============0455054384==-- From rucus-bounces@ietf.org Mon Nov 17 11:31:02 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 941023A6A1F; Mon, 17 Nov 2008 11:31:02 -0800 (PST) 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 27A693A6A1F for ; Mon, 17 Nov 2008 11:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 chK9nmvOpwOh for ; Mon, 17 Nov 2008 11:30:59 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id CD97D3A696D for ; Mon, 17 Nov 2008 11:30:46 -0800 (PST) Received: from [130.129.95.102] (account dyork [130.129.95.102] verified) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 37141912; Mon, 17 Nov 2008 19:30:45 +0000 Message-Id: <6141E9EB-BE4A-4582-BD3B-32293DE4E999@voxeo.com> From: Dan York To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 17 Nov 2008 13:30:44 -0600 References: X-Mailer: Apple Mail (2.929.2) Cc: rucus@ietf.org Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes, Thanks for taking the minutes.... only one minor detail- the list of participants does not include either Dan Wing or myself. Unless I imagined it... Dan On Nov 17, 2008, at 12:59 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Meeting Minutes > =============== > > Participants: > > - Hannes Tschofenig > - Mary Barnes > - David Schwartz > - Roger Marshall > - Kai Fischer > - Jan Seedorf > - Keith Drage > - Juergen Quitteck > - Thomas Froment > - Hendrik Scholz > - Jiri Kuthan > - Victor Pascual > - Salvatore Loreto > - Raphael Coeffic > > Meeting Minutes: Hannes Tschofenig > > Hannes gives a short introduction of the history of the RUCUS EG. > > Dan: Proposal for forming an EG took longer and requires folks to > write > short documents. > > Are we heading along the right path? Why didn't we got something done? > > Juergen: We have written drafts already. I have problems understandign > the intention of the IESG. > I don't see on the path they are willing to set us. > > Keith: Why do you want to know? > Media CTRL did not exist as a WG for a long time and the group met at > every IETF meeting. > > Juergen: What is the policy applied here? > > Dan: Step back to IETF#71 there was a lot of discussion and a lot of > push-back on providing differnet solutions. > > Keith: You still don't know which direction you would like to go. > > Mary: They are not going to give us directions. This group should put > together some building blocks together. > > Dan: The way forward was to create smaller, more generic building > blocks > > > David: What is a success or a failure of an EG? > > Keith: You still need someone to chair the group. > > Dan: Who is writing the drafts? > > David: There are drafts already. > We should be re-using what is already out there. > > Dan: Look at the proposed charter and what it wants from the small > drafts. > The existing drafts don't discuss the 4 points. > > David: Individual building blocks work in isolation. > > Dan: Should we go back to the ADs and ask them for a different > approach? > > > David: Where does the problem come in? Which part of the end-to-end > chain do we need to investigate? > One problem at the edge, one problem at the interworking points, etc. > > Keith: The EG does not help you solving the scope problems. > > David: The problem is only at the edge, Hadriel says. > I don't think that this is correct. > SMS is a fascinating use case. > Going to the spam score: where is it used? > > Dan: RFC 5149 provided potential solutions. It gives you the overall > problem statement but what are the specific solutions that have to be > put into an architecture. > > David: We need to bring the solutions down to earth. > RFC 5149 should be used heavily but it misses the architecture. It > misses the context. > > Thomas: The charter does not provide the architecture. Every document > needs to capture it. > > David: The use cases are so different: IMS, VoIP, SMS > We are not scoping it. > > Dan: How do we move the discussion forward? > I hear that we need a framework or a scope. > > Hendrik: Summarizes the SPIT attack in Germany. > Nobody knows what SPIT is going to look like. We would like to get > some > feedback messages for the users towards the operator. > > David: You are describing solutions for unwanted calls. > Without looking at where the problems came from is quite easy. > > Raphael: The problem is always moving as adversaries use different > attack mechanisms. You need a lot of building blocks for different > categories. > > Jan: The phones were directly attack. > > David: This is very good input. We need these "problem vectors". > > Dan: We could look at them as one action items. > > Jan: Well. The solution on how to provide feedback would have helped. > > Dan: We shouldn't discuss these solutions. > What actions should we take? > > David: It would be helpful to document about what is happening on > email > spam. > > Dan: David is going to write a document about email spam. Hannes > should > write something about XMPP spam. > David can you write something about the XConnect experience. > > Juergen: We are maintaing an incident list since years. We can write > up > a few of them. > We could put the list into a draft and ask folks to write up the > details. > Many of the cases are "mixed cases". > > Jan: We need to be careful to scope it too much on the current Spam > attacks. An attacker would change > > David: Spam is about economics and it takes some time to change the > economics. > > Dan: Your point is taken. Right now we don't have a lot of input and > we > should put them on paper. > Do folks be willing to look at other communities? David, can you work > with the email folks? Hannes, can you work on XMPP spam? > > Hannes: Yes, I will talk with Peter. > > David: Yes. > > Dan: Spam is a perception issue. Spam for you might not be spam for > me. > > Dan Wing: Email has evolved from open relays to DKIM and with SIP we > are > still at the early days of email. > The email community has figured out ways to overcome the problems of > SBCs and to get identity to work. > > David: The fear of SBCs has slowed things down. > > Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT > area. > > Dan: It would be useful to have a document. > > Hannes, Jan, Dan York, Dan Wing: Discussion about the differences > between DKIM and SIP Identity. > > David: You have been silent, Jiri. > > Jiri: SIP Identity has a too strong identity signature mechanism. > We do re-write the SDP to deal with NATs but we have a classical SIP > Proxy deployment. > > Dan: Jan, can you write a document about the differences between DKIM > and SIP Identity? > > Jan: Would do it when some folks in this room help me with it. > > Dan Wing: What is the target audience? > > Dan: The folks in the RUCUS group. > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus -- 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 Mon Nov 17 11:44:34 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 9CAEC3A6A1A; Mon, 17 Nov 2008 11:44:34 -0800 (PST) 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 54D453A6A1A for ; Mon, 17 Nov 2008 11:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.441, 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 YJhCrSdDk9af for ; Mon, 17 Nov 2008 11:44:33 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9F43E3A68D4 for ; Mon, 17 Nov 2008 11:44:32 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAHJiUTD016563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Nov 2008 20:44:30 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAHJiR7m014981; Mon, 17 Nov 2008 20:44:30 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:44:28 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Nov 2008 20:44:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Nov 2008 21:36:52 +0200 Message-ID: In-Reply-To: <6141E9EB-BE4A-4582-BD3B-32293DE4E999@voxeo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Meeting Minutes from F2F at IETF#73 Thread-Index: AclI6v7GrDvc0M+YTYqYpTqxpiJxwwAQkBGg References: <6141E9EB-BE4A-4582-BD3B-32293DE4E999@voxeo.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Dan York" X-OriginalArrivalTime: 17 Nov 2008 19:44:23.0067 (UTC) FILETIME=[E3F3FEB0:01C948EC] Cc: rucus@ietf.org Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 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 Sorry. Tiny mistake >-----Original Message----- >From: ext Dan York [mailto:dyork@voxeo.com] >Sent: 17 November, 2008 21:31 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: rucus@ietf.org >Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 > >Hannes, > >Thanks for taking the minutes.... only one minor detail- the >list of participants does not include either Dan Wing or myself. > >Unless I imagined it... > >Dan > >On Nov 17, 2008, at 12:59 PM, Tschofenig, Hannes (NSN - >FI/Espoo) wrote: > >> Meeting Minutes >> =============== >> >> Participants: >> >> - Hannes Tschofenig >> - Mary Barnes >> - David Schwartz >> - Roger Marshall >> - Kai Fischer >> - Jan Seedorf >> - Keith Drage >> - Juergen Quitteck >> - Thomas Froment >> - Hendrik Scholz >> - Jiri Kuthan >> - Victor Pascual >> - Salvatore Loreto >> - Raphael Coeffic >> >> Meeting Minutes: Hannes Tschofenig >> >> Hannes gives a short introduction of the history of the RUCUS EG. >> >> Dan: Proposal for forming an EG took longer and requires folks to >> write short documents. >> >> Are we heading along the right path? Why didn't we got >something done? >> >> Juergen: We have written drafts already. I have problems >understandign >> the intention of the IESG. >> I don't see on the path they are willing to set us. >> >> Keith: Why do you want to know? >> Media CTRL did not exist as a WG for a long time and the >group met at >> every IETF meeting. >> >> Juergen: What is the policy applied here? >> >> Dan: Step back to IETF#71 there was a lot of discussion and a lot of >> push-back on providing differnet solutions. >> >> Keith: You still don't know which direction you would like to go. >> >> Mary: They are not going to give us directions. This group >should put >> together some building blocks together. >> >> Dan: The way forward was to create smaller, more generic building >> blocks >> >> >> David: What is a success or a failure of an EG? >> >> Keith: You still need someone to chair the group. >> >> Dan: Who is writing the drafts? >> >> David: There are drafts already. >> We should be re-using what is already out there. >> >> Dan: Look at the proposed charter and what it wants from the small >> drafts. >> The existing drafts don't discuss the 4 points. >> >> David: Individual building blocks work in isolation. >> >> Dan: Should we go back to the ADs and ask them for a different >> approach? >> >> >> David: Where does the problem come in? Which part of the end-to-end >> chain do we need to investigate? >> One problem at the edge, one problem at the interworking points, etc. >> >> Keith: The EG does not help you solving the scope problems. >> >> David: The problem is only at the edge, Hadriel says. >> I don't think that this is correct. >> SMS is a fascinating use case. >> Going to the spam score: where is it used? >> >> Dan: RFC 5149 provided potential solutions. It gives you the overall >> problem statement but what are the specific solutions that >have to be >> put into an architecture. >> >> David: We need to bring the solutions down to earth. >> RFC 5149 should be used heavily but it misses the architecture. It >> misses the context. >> >> Thomas: The charter does not provide the architecture. Every >document >> needs to capture it. >> >> David: The use cases are so different: IMS, VoIP, SMS We are not >> scoping it. >> >> Dan: How do we move the discussion forward? >> I hear that we need a framework or a scope. >> >> Hendrik: Summarizes the SPIT attack in Germany. >> Nobody knows what SPIT is going to look like. We would like to get >> some feedback messages for the users towards the operator. >> >> David: You are describing solutions for unwanted calls. >> Without looking at where the problems came from is quite easy. >> >> Raphael: The problem is always moving as adversaries use different >> attack mechanisms. You need a lot of building blocks for different >> categories. >> >> Jan: The phones were directly attack. >> >> David: This is very good input. We need these "problem vectors". >> >> Dan: We could look at them as one action items. >> >> Jan: Well. The solution on how to provide feedback would have helped. >> >> Dan: We shouldn't discuss these solutions. >> What actions should we take? >> >> David: It would be helpful to document about what is happening on >> email spam. >> >> Dan: David is going to write a document about email spam. Hannes >> should write something about XMPP spam. >> David can you write something about the XConnect experience. >> >> Juergen: We are maintaing an incident list since years. We can write >> up a few of them. >> We could put the list into a draft and ask folks to write up the >> details. >> Many of the cases are "mixed cases". >> >> Jan: We need to be careful to scope it too much on the current Spam >> attacks. An attacker would change >> >> David: Spam is about economics and it takes some time to change the >> economics. >> >> Dan: Your point is taken. Right now we don't have a lot of input and >> we should put them on paper. >> Do folks be willing to look at other communities? David, can >you work >> with the email folks? Hannes, can you work on XMPP spam? >> >> Hannes: Yes, I will talk with Peter. >> >> David: Yes. >> >> Dan: Spam is a perception issue. Spam for you might not be spam for >> me. >> >> Dan Wing: Email has evolved from open relays to DKIM and with SIP we >> are still at the early days of email. >> The email community has figured out ways to overcome the problems of >> SBCs and to get identity to work. >> >> David: The fear of SBCs has slowed things down. >> >> Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT >> area. >> >> Dan: It would be useful to have a document. >> >> Hannes, Jan, Dan York, Dan Wing: Discussion about the differences >> between DKIM and SIP Identity. >> >> David: You have been silent, Jiri. >> >> Jiri: SIP Identity has a too strong identity signature mechanism. >> We do re-write the SDP to deal with NATs but we have a classical SIP >> Proxy deployment. >> >> Dan: Jan, can you write a document about the differences >between DKIM >> and SIP Identity? >> >> Jan: Would do it when some folks in this room help me with it. >> >> Dan Wing: What is the target audience? >> >> Dan: The folks in the RUCUS group. >> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus > >-- >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 Mon Nov 17 16:09: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 ADADE3A6A8D; Mon, 17 Nov 2008 16:09:45 -0800 (PST) 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 5FC823A67F3 for ; Mon, 17 Nov 2008 16:09:44 -0800 (PST) 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 M3IIg7IwVtbK for ; Mon, 17 Nov 2008 16:09:43 -0800 (PST) Received: from brian.123.org (brian.123.org [78.47.108.129]) by core3.amsl.com (Postfix) with ESMTP id 5D5B33A6844 for ; Mon, 17 Nov 2008 16:09:43 -0800 (PST) Received: from [194.97.181.241] (unknown [194.97.181.241]) by brian.123.org (Postfix) with ESMTP id 81C13C38168 for ; Tue, 18 Nov 2008 00:09:41 +0000 (UTC) Message-ID: <492207C3.8040402@123.org> Date: Tue, 18 Nov 2008 01:09:39 +0100 From: Hendrik Scholz User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: rucus@ietf.org Subject: [Rucus] case study of the recent VoIP attack 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi! During the f2f meeting the recent 'SPIT' case in Europe (esp. Germany) came up. Klaus Darilion already wrote a good summary on this: http://www.ipcom.at/index.php?id=565 We do know a couple of weaknesses in current IAD/CPE/UAS/endpoint implementations. These are not protocol weaknesses but rather pitfalls that (may) exist in endpoints. I agreed to write these up but before starting just like to know what kind of format would be best. draft-style? The content outline I think about would be along the lines of mistakes that UASes could make when interpreting inbound messages, i.e. - missing/wrong RURI checks - accepting From/P-Asserted-Identity/... as valid - accepting traffic from everywhere Focus (from my point of view) would not be on media but on mostly on SIP layer as well as some IP stuff. Cheers, Hendrik -- Hendrik Scholz _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Nov 17 16:11:55 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 08B663A6844; Mon, 17 Nov 2008 16:11:55 -0800 (PST) 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 E72EC3A6844 for ; Mon, 17 Nov 2008 16:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=1.368, 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 OWUAfqIp3LDw for ; Mon, 17 Nov 2008 16:11:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id AF80E3A67F3 for ; Mon, 17 Nov 2008 16:11:52 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAI0BjVw030041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Nov 2008 01:11:45 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAI0Bdkc020602; Tue, 18 Nov 2008 01:11:45 +0100 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 01:11:02 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2008 01:11:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 02:11:00 +0200 Message-ID: In-Reply-To: <492207C3.8040402@123.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] case study of the recent VoIP attack Thread-Index: AclJEgGwxN61hadUTbOCqoe+9OvSVQAQvX8g References: <492207C3.8040402@123.org> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hendrik Scholz" , X-OriginalArrivalTime: 18 Nov 2008 00:11:01.0477 (UTC) FILETIME=[23BFA150:01C94912] Subject: Re: [Rucus] case study of the recent VoIP attack 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 A writeup in a draft style format would be good. Ciao Hannes >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of ext Hendrik Scholz >Sent: 18 November, 2008 02:10 >To: rucus@ietf.org >Subject: [Rucus] case study of the recent VoIP attack > >Hi! > >During the f2f meeting the recent 'SPIT' case in Europe (esp. >Germany) came up. Klaus Darilion already wrote a good summary on >this: http://www.ipcom.at/index.php?id=565 > >We do know a couple of weaknesses in current >IAD/CPE/UAS/endpoint implementations. These are not protocol >weaknesses but rather pitfalls that (may) exist in endpoints. > >I agreed to write these up but before starting just like to >know what kind of format would be best. draft-style? > >The content outline I think about would be along the lines of >mistakes that UASes could make when interpreting inbound messages, i.e. > - missing/wrong RURI checks > - accepting From/P-Asserted-Identity/... as valid > - accepting traffic from everywhere > >Focus (from my point of view) would not be on media but on >mostly on SIP layer as well as some IP stuff. > >Cheers, > Hendrik > >-- >Hendrik Scholz >_______________________________________________ >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 Tue Nov 25 14:19:51 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 8946628C1C9; Tue, 25 Nov 2008 14:19:51 -0800 (PST) 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 8150428C1C8 for ; Tue, 25 Nov 2008 14:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 WIdErhbvmEnY for ; Tue, 25 Nov 2008 14:19:48 -0800 (PST) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 456363A6C68 for ; Tue, 25 Nov 2008 14:19:48 -0800 (PST) Received: from [66.65.228.203] (account dyork HELO pc-00144.lodestar2.dyndns.org) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 37372782 for rucus@ietf.org; Tue, 25 Nov 2008 22:19:44 +0000 Message-Id: From: Dan York To: rucus BoF Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 17:19:43 -0500 References: X-Mailer: Apple Mail (2.929.2) Subject: [Rucus] Updated Meeting Minutes from F2F at IETF#73 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: multipart/mixed; boundary="===============1807446923==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org --===============1807446923== Content-Type: multipart/alternative; boundary=Apple-Mail-191-236280499 --Apple-Mail-191-236280499 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit RUCUS list members, FYI, I've just edited Hannes' minutes to reflect the correct RFC number and the presence of Dan Wing and I. I'm re-sending these to the list with the corrections because I want to link to them from another upcoming message. Thanks to everyone who attended, Dan Begin forwarded message: From: "Tschofenig, Hannes (NSN - FI/Espoo)" Date: November 17, 2008 1:59:22 PM EST To: Subject: [Rucus] Meeting Minutes from F2F at IETF#73 Meeting Minutes =============== Participants: - Hannes Tschofenig - Mary Barnes - David Schwartz - Roger Marshall - Kai Fischer - Jan Seedorf - Keith Drage - Juergen Quitteck - Thomas Froment - Hendrik Scholz - Jiri Kuthan - Victor Pascual - Salvatore Loreto - Raphael Coeffic - Dan Wing - Dan York Meeting Minutes: Hannes Tschofenig Hannes gives a short introduction of the history of the RUCUS EG. Dan: Proposal for forming an EG took longer and requires folks to write short documents. Are we heading along the right path? Why didn't we got something done? Juergen: We have written drafts already. I have problems understandign the intention of the IESG. I don't see on the path they are willing to set us. Keith: Why do you want to know? Media CTRL did not exist as a WG for a long time and the group met at every IETF meeting. Juergen: What is the policy applied here? Dan: Step back to IETF#71 there was a lot of discussion and a lot of push-back on providing differnet solutions. Keith: You still don't know which direction you would like to go. Mary: They are not going to give us directions. This group should put together some building blocks together. Dan: The way forward was to create smaller, more generic building blocks David: What is a success or a failure of an EG? Keith: You still need someone to chair the group. Dan: Who is writing the drafts? David: There are drafts already. We should be re-using what is already out there. Dan: Look at the proposed charter and what it wants from the small drafts. The existing drafts don't discuss the 4 points. David: Individual building blocks work in isolation. Dan: Should we go back to the ADs and ask them for a different approach? David: Where does the problem come in? Which part of the end-to-end chain do we need to investigate? One problem at the edge, one problem at the interworking points, etc. Keith: The EG does not help you solving the scope problems. David: The problem is only at the edge, Hadriel says. I don't think that this is correct. SMS is a fascinating use case. Going to the spam score: where is it used? Dan: RFC 5039 provided potential solutions. It gives you the overall problem statement but what are the specific solutions that have to be put into an architecture. David: We need to bring the solutions down to earth. RFC 5039 should be used heavily but it misses the architecture. It misses the context. Thomas: The charter does not provide the architecture. Every document needs to capture it. David: The use cases are so different: IMS, VoIP, SMS We are not scoping it. Dan: How do we move the discussion forward? I hear that we need a framework or a scope. Hendrik: Summarizes the SPIT attack in Germany. Nobody knows what SPIT is going to look like. We would like to get some feedback messages for the users towards the operator. David: You are describing solutions for unwanted calls. Without looking at where the problems came from is quite easy. Raphael: The problem is always moving as adversaries use different attack mechanisms. You need a lot of building blocks for different categories. Jan: The phones were directly attack. David: This is very good input. We need these "problem vectors". Dan: We could look at them as one action items. Jan: Well. The solution on how to provide feedback would have helped. Dan: We shouldn't discuss these solutions. What actions should we take? David: It would be helpful to document about what is happening on email spam. Dan: David is going to write a document about email spam. Hannes should write something about XMPP spam. David can you write something about the XConnect experience. Juergen: We are maintaing an incident list since years. We can write up a few of them. We could put the list into a draft and ask folks to write up the details. Many of the cases are "mixed cases". Jan: We need to be careful to scope it too much on the current Spam attacks. An attacker would change David: Spam is about economics and it takes some time to change the economics. Dan: Your point is taken. Right now we don't have a lot of input and we should put them on paper. Do folks be willing to look at other communities? David, can you work with the email folks? Hannes, can you work on XMPP spam? Hannes: Yes, I will talk with Peter. David: Yes. Dan: Spam is a perception issue. Spam for you might not be spam for me. Dan Wing: Email has evolved from open relays to DKIM and with SIP we are still at the early days of email. The email community has figured out ways to overcome the problems of SBCs and to get identity to work. David: The fear of SBCs has slowed things down. Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT area. Dan: It would be useful to have a document. Hannes, Jan, Dan York, Dan Wing: Discussion about the differences between DKIM and SIP Identity. David: You have been silent, Jiri. Jiri: SIP Identity has a too strong identity signature mechanism. We do re-write the SDP to deal with NATs but we have a classical SIP Proxy deployment. Dan: Jan, can you write a document about the differences between DKIM and SIP Identity? Jan: Would do it when some folks in this room help me with it. Dan Wing: What is the target audience? Dan: The folks in the RUCUS group. -- 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 --Apple-Mail-191-236280499 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable RUCUS list = members,

FYI, I've just edited Hannes' minutes to = reflect the correct RFC number and the presence of Dan Wing and I. =  I'm re-sending these to the list with the corrections because I = want to link to them from another upcoming = message.

Thanks to everyone who = attended,
Dan



Begin = forwarded message:

From: = "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Date: November 17, 2008 1:59:22 PM = EST
Subject: = [Rucus] Meeting Minutes from F2F at = IETF#73

Dan: We could look at them as one = action items.

Jan: Well. The solution on how to provide feedback = would have helped.

Dan: We shouldn't discuss these solutions. =
What actions should we take?

David: It would be helpful to = document about what is happening on email
spam.

Dan: David is = going to write a document about email spam. Hannes should
write = something about XMPP spam.
David can you write something about the = XConnect experience.

Juergen: We are maintaing an incident list = since years. We can write up
a few of them.
We could put the list = into a draft and ask folks to write up the
details.
Many of the = cases are "mixed cases".

Jan: We need to be careful to scope it = too much on the current Spam
attacks. An attacker would = change

David: Spam is about economics and it takes some time to = change the
economics.

Dan: Your point is taken. Right now we = don't have a lot of input and we
should put them on paper.
Do = folks be willing to look at other communities? David, can you = work
with the email folks? Hannes, can you work on XMPP spam? =

Hannes: Yes, I will talk with Peter.

David: Yes. =

Dan: Spam is a perception issue. Spam for you might not be spam = for me.

Dan Wing: Email has evolved from open relays to DKIM and = with SIP we are
still at the early days of email.
The email = community has figured out ways to overcome the problems of
SBCs and = to get identity to work.

David: The fear of SBCs has slowed = things down.

Dan Wing: True. And as a chair of BEHAVE I = recognize this in the NAT
area.

Dan: It would be useful to = have a document.  

Hannes, Jan, Dan York, Dan Wing: = Discussion about the differences
between DKIM and SIP Identity. =

David: You have been silent, Jiri.

Jiri: SIP Identity = has a too strong identity signature mechanism.
We do re-write the = SDP to deal with NATs but we have a classical SIP
Proxy deployment. =

Dan: Jan, can you write a document about the differences between = DKIM
and SIP Identity?

Jan: Would do it when some folks in = this room help me with it.

Dan Wing: What is the target = audience?

Dan: The folks in the RUCUS group. =


-- 
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

Build voice applications based on open = standards.





= --Apple-Mail-191-236280499-- --===============1807446923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus --===============1807446923==-- From rucus-bounces@ietf.org Thu Nov 27 06:05:46 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 AA8143A68FE; Thu, 27 Nov 2008 06:05:46 -0800 (PST) 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 12BA23A68FE for ; Thu, 27 Nov 2008 06:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 hP8l7jMYq6Ui for ; Thu, 27 Nov 2008 06:05:43 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7ADEA3A68E0 for ; Thu, 27 Nov 2008 06:05:43 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 27 Nov 2008 09:04:12 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 27 Nov 2008 09:04:12 -0500 From: Hadriel Kaplan To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "rucus@ietf.org" Date: Thu, 27 Nov 2008 09:03:13 -0500 Thread-Topic: Meeting Minutes from F2F at IETF#73 Thread-Index: AclIo3QAROiAkuBcQ6itNYV4difynwH7ijjw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 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 Huh, sorry I missed the meeting - I hadn't looked in this email folder for a while. One correction regarding your minutes: I never said the problem is only at the edge. Quite the opposite, my problem is in the middle. For most of my customer's, they control the subscribers (the "edge") pretty well. They can stop any individual UA or PBX from sending more than X SIP INVITEs/MESSAGEs/foo in time period Y, with complete control over X and Y values (and often more settings/knobs than just that). Basically every popular SBC I know of offers that level of control these days - some in hardware, some just in software. When I think of SPAM, it seems to me only useful if one can generate lots of it, due to the low success rate. So if my customers can stop UA's from sending their spam at any rate above normal phone call/SMS rates, I'm not worried about SPAM from them so much. Botnets/zombies worry me, but for a different reason really - most SBCs have protection mechanisms to protect the core at all costs, including just knocking out mis-behaving UA's by dynamically blacklisting them in hardware ACLs for periods of time. That was a huge selling feature for my company when we first released it 4 years ago. We developed a small MS-Windows program that could spoof hundreds of thousands of UA's and flood the SIP proxy with SIP messages of any type at ~100,000 msgs/sec (~500Mbps) from a normal Windows laptop, and we gave the program away to customers for free to prove what zombies could do, or a registration avalanche, or even some script kiddie. Since similar such attack tools are now available on the Internet, my assumption is operators who use other SBC-type boxes are figuring out how to handle it too. What concerns me for it though is that the only recourse is to throttle or blacklist the zombies, so a coordinated zombie attack essentially knocks out service for infected users during an attack. I don't think that's a RUCUS-type problem, and I think it's the only recourse, but it's worrisome for a public communications service. Anyway... so for me (not everyone), my concern is not about SPAM from subscriber edge. It's from SPAM through the peering interconnects, from *peers*. Because at some point in the future, some provider in the interconnected islands of providers will connect NoControlProvider.com into the chain, and all hell could break loose. Cats and Dogs living together... mass hysteria. My customers are telling me not to worry about it; that it won't happen, and if it does they'll just cut off that link in the chain until they fix themselves. But I think they could be wrong. There are legal implications to shutting off voice traffic, and it takes time. I'd rather plan for the worst-case. And the problem is exacerbated by my own product category, ironically. SBC's anonymize so much of the SIP signaling that there's very little to base identity decisions on by the time you've passed through a provider or two. So I want to help fix it, by providing the necessary information to help stop it, so long as it doesn't compromise the goals of the "legitimate" providers. And doing what SBC's currently do is basically not avoidable, because by definition it's what providers wish to do. And this is only my opinion for my common customer types - I have no stance, opinion, or knowledge of what is important for other SIP deployment types. -hadriel > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, November 17, 2008 1:59 PM > To: rucus@ietf.org > Subject: [Rucus] Meeting Minutes from F2F at IETF#73 > > Meeting Minutes > =============== > > Participants: > > - Hannes Tschofenig > - Mary Barnes > - David Schwartz > - Roger Marshall > - Kai Fischer > - Jan Seedorf > - Keith Drage > - Juergen Quitteck > - Thomas Froment > - Hendrik Scholz > - Jiri Kuthan > - Victor Pascual > - Salvatore Loreto > - Raphael Coeffic > > Meeting Minutes: Hannes Tschofenig > > Hannes gives a short introduction of the history of the RUCUS EG. > > Dan: Proposal for forming an EG took longer and requires folks to write > short documents. > > Are we heading along the right path? Why didn't we got something done? > > Juergen: We have written drafts already. I have problems understandign > the intention of the IESG. > I don't see on the path they are willing to set us. > > Keith: Why do you want to know? > Media CTRL did not exist as a WG for a long time and the group met at > every IETF meeting. > > Juergen: What is the policy applied here? > > Dan: Step back to IETF#71 there was a lot of discussion and a lot of > push-back on providing differnet solutions. > > Keith: You still don't know which direction you would like to go. > > Mary: They are not going to give us directions. This group should put > together some building blocks together. > > Dan: The way forward was to create smaller, more generic building blocks > > > David: What is a success or a failure of an EG? > > Keith: You still need someone to chair the group. > > Dan: Who is writing the drafts? > > David: There are drafts already. > We should be re-using what is already out there. > > Dan: Look at the proposed charter and what it wants from the small > drafts. > The existing drafts don't discuss the 4 points. > > David: Individual building blocks work in isolation. > > Dan: Should we go back to the ADs and ask them for a different approach? > > > David: Where does the problem come in? Which part of the end-to-end > chain do we need to investigate? > One problem at the edge, one problem at the interworking points, etc. > > Keith: The EG does not help you solving the scope problems. > > David: The problem is only at the edge, Hadriel says. > I don't think that this is correct. > SMS is a fascinating use case. > Going to the spam score: where is it used? > > Dan: RFC 5149 provided potential solutions. It gives you the overall > problem statement but what are the specific solutions that have to be > put into an architecture. > > David: We need to bring the solutions down to earth. > RFC 5149 should be used heavily but it misses the architecture. It > misses the context. > > Thomas: The charter does not provide the architecture. Every document > needs to capture it. > > David: The use cases are so different: IMS, VoIP, SMS > We are not scoping it. > > Dan: How do we move the discussion forward? > I hear that we need a framework or a scope. > > Hendrik: Summarizes the SPIT attack in Germany. > Nobody knows what SPIT is going to look like. We would like to get some > feedback messages for the users towards the operator. > > David: You are describing solutions for unwanted calls. > Without looking at where the problems came from is quite easy. > > Raphael: The problem is always moving as adversaries use different > attack mechanisms. You need a lot of building blocks for different > categories. > > Jan: The phones were directly attack. > > David: This is very good input. We need these "problem vectors". > > Dan: We could look at them as one action items. > > Jan: Well. The solution on how to provide feedback would have helped. > > Dan: We shouldn't discuss these solutions. > What actions should we take? > > David: It would be helpful to document about what is happening on email > spam. > > Dan: David is going to write a document about email spam. Hannes should > write something about XMPP spam. > David can you write something about the XConnect experience. > > Juergen: We are maintaing an incident list since years. We can write up > a few of them. > We could put the list into a draft and ask folks to write up the > details. > Many of the cases are "mixed cases". > > Jan: We need to be careful to scope it too much on the current Spam > attacks. An attacker would change > > David: Spam is about economics and it takes some time to change the > economics. > > Dan: Your point is taken. Right now we don't have a lot of input and we > should put them on paper. > Do folks be willing to look at other communities? David, can you work > with the email folks? Hannes, can you work on XMPP spam? > > Hannes: Yes, I will talk with Peter. > > David: Yes. > > Dan: Spam is a perception issue. Spam for you might not be spam for me. > > Dan Wing: Email has evolved from open relays to DKIM and with SIP we are > still at the early days of email. > The email community has figured out ways to overcome the problems of > SBCs and to get identity to work. > > David: The fear of SBCs has slowed things down. > > Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT > area. > > Dan: It would be useful to have a document. > > Hannes, Jan, Dan York, Dan Wing: Discussion about the differences > between DKIM and SIP Identity. > > David: You have been silent, Jiri. > > Jiri: SIP Identity has a too strong identity signature mechanism. > We do re-write the SDP to deal with NATs but we have a classical SIP > Proxy deployment. > > Dan: Jan, can you write a document about the differences between DKIM > and SIP Identity? > > Jan: Would do it when some folks in this room help me with it. > > Dan Wing: What is the target audience? > > Dan: The folks in the RUCUS group. > > _______________________________________________ > 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 Thu Nov 27 06:30: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 0737D3A687D; Thu, 27 Nov 2008 06:30:44 -0800 (PST) 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 2956C3A687D for ; Thu, 27 Nov 2008 06:30:43 -0800 (PST) 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 g8mmJRH5Mza9 for ; Thu, 27 Nov 2008 06:30:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id DCCC23A67B0 for ; Thu, 27 Nov 2008 06:30:40 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAREUYH9023343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Nov 2008 15:30:34 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAREUXYF013983; Thu, 27 Nov 2008 15:30:34 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 15:30:33 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Nov 2008 15:30:33 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Meeting Minutes from F2F at IETF#73 Thread-Index: AclIo3QAROiAkuBcQ6itNYV4difynwH7ijjwAAKQAYA= References: From: "Charzinski, Joachim (NSN - DE/Munich)" To: "ext Hadriel Kaplan" , "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 27 Nov 2008 14:30:33.0837 (UTC) FILETIME=[B4FD01D0:01C9509C] Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hadriel, this is very much in line with the findings of our former = anti-SPIT activity. The main technical problem is SPIT = coming in through some peering link, especially if you = need to accept calls from unreliable IDs. = Conseqently, the main benefit of an anti-SPIT system is = not automated blocking (a critical service availability = issue) but rather OPEX savings through automated incident = alarming and documentation, so in case of an incident - you get an alarm with a hint what to block - you have the necessary documentation filed in case = someone complains later = Best regards Joachim. -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of e= xt Hadriel Kaplan Sent: Thursday, November 27, 2008 3:03 PM To: Tschofenig, Hannes (NSN - FI/Espoo); rucus@ietf.org Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 Huh, sorry I missed the meeting - I hadn't looked in this email folder for = a while. One correction regarding your minutes: I never said the problem is only at = the edge. Quite the opposite, my problem is in the middle. For most of my customer's, they control the subscribers (the "edge") pretty= well. They can stop any individual UA or PBX from sending more than X SIP= INVITEs/MESSAGEs/foo in time period Y, with complete control over X and Y = values (and often more settings/knobs than just that). Basically every pop= ular SBC I know of offers that level of control these days - some in hardwa= re, some just in software. When I think of SPAM, it seems to me only usefu= l if one can generate lots of it, due to the low success rate. So if my cu= stomers can stop UA's from sending their spam at any rate above normal phon= e call/SMS rates, I'm not worried about SPAM from them so much. Botnets/zombies worry me, but for a different reason really - most SBCs hav= e protection mechanisms to protect the core at all costs, including just kn= ocking out mis-behaving UA's by dynamically blacklisting them in hardware A= CLs for periods of time. That was a huge selling feature for my company wh= en we first released it 4 years ago. We developed a small MS-Windows progr= am that could spoof hundreds of thousands of UA's and flood the SIP proxy w= ith SIP messages of any type at ~100,000 msgs/sec (~500Mbps) from a normal = Windows laptop, and we gave the program away to customers for free to prove= what zombies could do, or a registration avalanche, or even some script ki= ddie. Since similar such attack tools are now available on the Internet, m= y assumption is operators who use other SBC-type boxes are figuring out how= to handle it too. What concerns me for it though is that the only recours= e is to throttle or blacklist the zombies, so a coordinated zombie attack e= ssentially knoc ks out service for infected users during an attack. I don't think that's = a RUCUS-type problem, and I think it's the only recourse, but it's worrisom= e for a public communications service. Anyway... so for me (not everyone), my concern is not about SPAM from subsc= riber edge. It's from SPAM through the peering interconnects, from *peers*= . Because at some point in the future, some provider in the interconnected= islands of providers will connect NoControlProvider.com into the chain, an= d all hell could break loose. Cats and Dogs living together... mass hyster= ia. My customers are telling me not to worry about it; that it won't happe= n, and if it does they'll just cut off that link in the chain until they fi= x themselves. But I think they could be wrong. There are legal implicatio= ns to shutting off voice traffic, and it takes time. I'd rather plan for t= he worst-case. And the problem is exacerbated by my own product category, = ironically. SBC's anonymize so much of the SIP signaling that there's very= little to base identity decisions on by the time you've passed through a p= rovider or two. So I want to help fix it, by providing the necessary infor= mation to help = stop it, so long as it doesn't compromise the goals of the "legitimate" pr= oviders. And doing what SBC's currently do is basically not avoidable, bec= ause by definition it's what providers wish to do. And this is only my opinion for my common customer types - I have no stance= , opinion, or knowledge of what is important for other SIP deployment types. -hadriel > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Monday, November 17, 2008 1:59 PM > To: rucus@ietf.org > Subject: [Rucus] Meeting Minutes from F2F at IETF#73 > > Meeting Minutes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Participants: > > - Hannes Tschofenig > - Mary Barnes > - David Schwartz > - Roger Marshall > - Kai Fischer > - Jan Seedorf > - Keith Drage > - Juergen Quitteck > - Thomas Froment > - Hendrik Scholz > - Jiri Kuthan > - Victor Pascual > - Salvatore Loreto > - Raphael Coeffic > > Meeting Minutes: Hannes Tschofenig > > Hannes gives a short introduction of the history of the RUCUS EG. > > Dan: Proposal for forming an EG took longer and requires folks to write > short documents. > > Are we heading along the right path? Why didn't we got something done? > > Juergen: We have written drafts already. I have problems understandign > the intention of the IESG. > I don't see on the path they are willing to set us. > > Keith: Why do you want to know? > Media CTRL did not exist as a WG for a long time and the group met at > every IETF meeting. > > Juergen: What is the policy applied here? > > Dan: Step back to IETF#71 there was a lot of discussion and a lot of > push-back on providing differnet solutions. > > Keith: You still don't know which direction you would like to go. > > Mary: They are not going to give us directions. This group should put > together some building blocks together. > > Dan: The way forward was to create smaller, more generic building blocks > > > David: What is a success or a failure of an EG? > > Keith: You still need someone to chair the group. > > Dan: Who is writing the drafts? > > David: There are drafts already. > We should be re-using what is already out there. > > Dan: Look at the proposed charter and what it wants from the small > drafts. > The existing drafts don't discuss the 4 points. > > David: Individual building blocks work in isolation. > > Dan: Should we go back to the ADs and ask them for a different approach? > > > David: Where does the problem come in? Which part of the end-to-end > chain do we need to investigate? > One problem at the edge, one problem at the interworking points, etc. > > Keith: The EG does not help you solving the scope problems. > > David: The problem is only at the edge, Hadriel says. > I don't think that this is correct. > SMS is a fascinating use case. > Going to the spam score: where is it used? > > Dan: RFC 5149 provided potential solutions. It gives you the overall > problem statement but what are the specific solutions that have to be > put into an architecture. > > David: We need to bring the solutions down to earth. > RFC 5149 should be used heavily but it misses the architecture. It > misses the context. > > Thomas: The charter does not provide the architecture. Every document > needs to capture it. > > David: The use cases are so different: IMS, VoIP, SMS > We are not scoping it. > > Dan: How do we move the discussion forward? > I hear that we need a framework or a scope. > > Hendrik: Summarizes the SPIT attack in Germany. > Nobody knows what SPIT is going to look like. We would like to get some > feedback messages for the users towards the operator. > > David: You are describing solutions for unwanted calls. > Without looking at where the problems came from is quite easy. > > Raphael: The problem is always moving as adversaries use different > attack mechanisms. You need a lot of building blocks for different > categories. > > Jan: The phones were directly attack. > > David: This is very good input. We need these "problem vectors". > > Dan: We could look at them as one action items. > > Jan: Well. The solution on how to provide feedback would have helped. > > Dan: We shouldn't discuss these solutions. > What actions should we take? > > David: It would be helpful to document about what is happening on email > spam. > > Dan: David is going to write a document about email spam. Hannes should > write something about XMPP spam. > David can you write something about the XConnect experience. > > Juergen: We are maintaing an incident list since years. We can write up > a few of them. > We could put the list into a draft and ask folks to write up the > details. > Many of the cases are "mixed cases". > > Jan: We need to be careful to scope it too much on the current Spam > attacks. An attacker would change > > David: Spam is about economics and it takes some time to change the > economics. > > Dan: Your point is taken. Right now we don't have a lot of input and we > should put them on paper. > Do folks be willing to look at other communities? David, can you work > with the email folks? Hannes, can you work on XMPP spam? > > Hannes: Yes, I will talk with Peter. > > David: Yes. > > Dan: Spam is a perception issue. Spam for you might not be spam for me. > > Dan Wing: Email has evolved from open relays to DKIM and with SIP we are > still at the early days of email. > The email community has figured out ways to overcome the problems of > SBCs and to get identity to work. > > David: The fear of SBCs has slowed things down. > > Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT > area. > > Dan: It would be useful to have a document. > > Hannes, Jan, Dan York, Dan Wing: Discussion about the differences > between DKIM and SIP Identity. > > David: You have been silent, Jiri. > > Jiri: SIP Identity has a too strong identity signature mechanism. > We do re-write the SDP to deal with NATs but we have a classical SIP > Proxy deployment. > > Dan: Jan, can you write a document about the differences between DKIM > and SIP Identity? > > Jan: Would do it when some folks in this room help me with it. > > Dan Wing: What is the target audience? > > Dan: The folks in the RUCUS group. > > _______________________________________________ > 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 ---------------------------------------------------------- Joachim Charzinski Nokia Siemens Networks Research, Technology and Platforms = Strategy & Vision / End-to-end Network Architecture Evolution = St.-Martin-Str. 53 Post box: D-80240 Muenchen D-81541 Muenchen Germany Tel: +49 89 636 79902 Joachim.Charzinski@nsn.com = http://www.nokiasiemensnetworks.com/global/ Think before you print Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens Net= works Management GmbH Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivin= en Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Nov 27 07:31:27 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 89FAA3A6945; Thu, 27 Nov 2008 07:31:27 -0800 (PST) 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 CC8423A6945 for ; Thu, 27 Nov 2008 07:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 LqykMbvmWmL5 for ; Thu, 27 Nov 2008 07:31:22 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AC3A63A68EF for ; Thu, 27 Nov 2008 07:31:22 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 27 Nov 2008 10:29:51 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 27 Nov 2008 10:29:48 -0500 From: Hadriel Kaplan To: "Charzinski, Joachim (NSN - DE/Munich)" , "Tschofenig, Hannes (NSN - FI/Espoo)" , "rucus@ietf.org" Date: Thu, 27 Nov 2008 10:28:50 -0500 Thread-Topic: [Rucus] Meeting Minutes from F2F at IETF#73 Thread-Index: AclIo3QAROiAkuBcQ6itNYV4difynwH7ijjwAAKQAYAAASt30A== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73 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 Yes my opinion too - this is more about reaction after the fact than pro-active blocking. And I figure there's so little information to go on right now, that there's little to go on to generate an alarm, and the ability to track it down is poor. All kinds of devices create CDR's, but they'll only tell you which peer sent it in, so it takes a long time and multiple NOC personnel of different providers to find out how it got in. And that's only after someone complains, because it's rather hard to alarm on anything other than unusual call rates or patterns from a given peer (and pattern checks are easily defeatable, IMO). And if we define a mechanism, no matter what we do it has a deployment problem: providers take years to upgrade and some will never do it, and certainly it doesn't happen all at once. That's what I liked about Dan's return-routability check or Jiri's Derive drafts: that they didn't need all domains to be upgraded to do them. But I still think they've got other issues/down-sides. So I submitted a draft several months ago for a P-Asserter header, which would identify the generating domain of a P-Asserted-Identity header, and sign it. (see http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-00) The purpose of that was to be able to (1) track these things down, (2) pull the more-likely-legitimate requests out of the weeds, and (3) provide data that can be used for verification or reputation, to NOT alarm on. It doesn't need UA's to do anything - only the peering proxies/SBCs/whatever, so it's got that going for it; but it still requires originating domains to do it, for the mechanism to be of much use, which is its Achilles heel. -hadriel > -----Original Message----- > From: Charzinski, Joachim (NSN - DE/Munich) > [mailto:joachim.charzinski@nsn.com] > Sent: Thursday, November 27, 2008 9:31 AM > > Hi Hadriel, > > this is very much in line with the findings of our former > anti-SPIT activity. The main technical problem is SPIT > coming in through some peering link, especially if you > need to accept calls from unreliable IDs. > > Conseqently, the main benefit of an anti-SPIT system is > not automated blocking (a critical service availability > issue) but rather OPEX savings through automated incident > alarming and documentation, so in case of an incident > - you get an alarm with a hint what to block > - you have the necessary documentation filed in case > someone complains later > > Best regards > > Joachim. _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus