From rucus-bounces@ietf.org Tue Aug 5 02:02:22 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 520B128C14B; Tue, 5 Aug 2008 02:02:22 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA963A6A94 for ; Tue, 5 Aug 2008 02:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 jBgcqrT-3G1V for ; Tue, 5 Aug 2008 02:02:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 011393A6CA9 for ; Tue, 5 Aug 2008 02:02:19 -0700 (PDT) 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 m7592mqK009668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Aug 2008 11:02:48 +0200 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 m75928ng003174 for ; Tue, 5 Aug 2008 11:02:48 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 11:02:47 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Aug 2008 11:02:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8F6DA.0247784F" Date: Tue, 5 Aug 2008 12:02:41 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RUCUS Charter Text v1 Thread-Index: Acj22gQQLU5HeJK4QTKoTwZDPsJauQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 05 Aug 2008 09:02:47.0203 (UTC) FILETIME=[07AB4F30:01C8F6DA] Subject: [Rucus] RUCUS Charter Text v1 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: , Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F6DA.0247784F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 As you might have noticed, we got stuck a bit with the charter discussions on the list. Hence, a few of us, namely Mary Barnes, Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, Cullen Jennings and Jan Seedorf, used the IETF 72 meeting to chat about the RUCUS charter.=20 Jonathan, Henning and I came up with a first text proposal based on the discussion we had during the meeting. Please find it in the attachment.=20 Please let us know whether you find the current charter text acceptable. Ciao Hannes ------_=_NextPart_001_01C8F6DA.0247784F Content-Type: text/plain; name="rucus-charter1.txt" Content-Transfer-Encoding: base64 Content-Description: rucus-charter1.txt Content-Disposition: attachment; filename="rucus-charter1.txt" VGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBpcyBhbiBhcHBsaWNhdGlvbi1s YXllciBjb250cm9sDQooc2lnbmFsaW5nKSBwcm90b2NvbCBmb3IgY3JlYXRpbmcsIG1vZGlmeWlu ZywgYW5kIHRlcm1pbmF0aW5nIHNlc3Npb25zDQp3aXRoIG9uZSBvciBtb3JlIHBhcnRpY2lwYW50 cy4gIFRoZXNlIHNlc3Npb25zIGluY2x1ZGUgSW50ZXJuZXQNCnRlbGVwaG9uZSBjYWxscywgbXVs dGltZWRpYSBkaXN0cmlidXRpb24sIGFuZCBtdWx0aW1lZGlhDQpjb25mZXJlbmNlcy4gTGlrZSBv dGhlciBjb21tdW5pY2F0aW9uIHByb3RvY29scywgU0lQIGlzIHN1c2NlcHRpYmxlIHRvDQp1bndh bnRlZCBjb21tdW5pY2F0aW9uIGF0dGVtcHRzLiAgUkZDIDUwMzkgYW5hbHl6ZXMgdGhlIHByb2Js ZW0gb2YNCnNwYW0gaW4gU0lQIGFuZCBleGFtaW5lcyB2YXJpb3VzIHBvc3NpYmxlIHNvbHV0aW9u cyB0aGF0IGhhdmUgYmVlbg0KZGlzY3Vzc2VkIGZvciBlbWFpbCBhbmQgY29uc2lkZXJzIHRoZWly IGFwcGxpY2FiaWxpdHkgdG8gU0lQLg0KDQpSRkMgNTAzOSBnaXZlcyBnb29kLCBoaWdoLWxldmVs IHJlY29tbWVuZGF0aW9ucyByZWdhcmRpbmcgZnV0dXJlIHdvcmssDQpuYW1lbHkgdG8gcHJvdmlk ZQ0KDQoqIFN0cm9uZyBJZGVudGl0eQ0KKiBXaGl0ZSBMaXN0cw0KKiBTb2x2ZSB0aGUgSW50cm9k dWN0aW9uIFByb2JsZW0NCiogRG9uJ3QgV2FpdCBVbnRpbCBJdCdzIFRvbyBMYXRlDQoNCkFtb25n IHRoZSBtYW55IGluZGl2aWR1YWwgbWVjaGFuaXNtcyB0aGF0IGFyZSBkaXNjdXNzZWQgaW4gUkZD DQo1MDM5IChpbmNsdWRpbmcgY29udGVudCBmaWx0ZXJpbmcsIGJsYWNrIGxpc3RzLCB3aGl0ZSBs aXN0cywNCmNvbnNlbnQtYmFzZWQgY29tbXVuaWNhdGlvbiwgcmVwdXRhdGlvbiBzeXN0ZW1zLCBh ZGRyZXNzIG9iZnVzY2F0aW9uLA0KbGltaXRlZCB1c2UgYWRkcmVzc2VzLCB0dXJpbmcgdGVzdHMs IGNvbXB1dGF0aW9uYWwgcHV6emxlcywgcGF5bWVudHMNCmF0IHJpc2ssIGNpcmNsZXMgb2YgdHJ1 c3QsIGFuZCBtYW55IG90aGVycykgdGhlcmUgaXMgbm8gY2xlYXIgZ3VpZGFuY2UNCm9uIHdoZXRo ZXIgb25lIG9mIHRoZSBtZWNoYW5pc21zIGxpc3RlZCAtIG9yIHNvbWV0aGluZyBlbHNlIGVudGly ZWx5IC0NCmlzIHN1YmplY3Qgb2YgYWRkaXRpb25hbCBzdGFuZGFyZHMgd29yay4gDQoNCkZ1cnRo ZXJtb3JlLCBzaW5jZSB0aGUgcHVibGljYXRpb24gb2YgUkZDIDUwMzksIG1hbnkgZG9jdW1lbnRz IGhhdmUNCmJlZW4gc3VibWl0dGVkIHRvIElFVEYgd2hpY2ggZGVmaW5lIGZyYW1ld29ya3MsIHBy b3Bvc2UgcHJvdG9jb2wNCmhlYWRlcnMsIG9yIGRvY3VtZW50IGFkZGl0aW9uYWwgZ3VpZGVsaW5l cyBvbiB0ZWNobmlxdWVzIGluIFJGQw0KNTAzOS4gVGhlc2UgZG9jdW1lbnRzIGluY2x1ZGU6DQoN CiogZHJhZnQtd2luZy1zaXBwaW5nLXNwYW0tc2NvcmUgDQoqIGRyYWZ0LWplbm5pbmdzLXNpcC1o YXNoY2FzaCANCiogZHJhZnQtdHNjaG9mZW5pZy1zaXBwaW5nLXNwaXQtcG9saWN5IA0KKiBkcmFm dC10c2Nob2ZlbmlnLXNpcHBpbmctY2FwdGNoYSANCiogZHJhZnQtbmljY29saW5pLXNpcHBpbmct ZmVlZGJhY2stc3BpdA0KDQpEZXNwaXRlIHRoZSBwbGV0aG9yYSBvZiBkb2N1bWVudHMsIHRoZXJl IGlzIGRlYmF0ZSBpbiB0aGUgY29tbXVuaXR5DQpvdmVyIHdoZXRoZXIgdGhlcmUgd291bGQgYmUg YW55IHZhbHVlIGluIHB1cnN1aW5nIGFueSBvciBhbGwgb2YNCnRoZXNlLiANCg0KVGhlIHB1cnBv c2Ugb2YgdGhpcyBleHBsb3JhdG9yeSBncm91cCBpcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGVy ZQ0KYXJlIG9uZSBvciBtb3JlIG1lY2hhbmlzbXMgZm9yIG1pdGlnYXRpb24gb2YgdW5zb2ljaXRl ZCBjb21tdW5pY2F0aW9uLCANCndoaWNoIHdvdWxkIGJlIHJlYXNvbmFibGUgc3ViamVjdHMgZm9y IHN0YW5kYXJkaXphdGlvbiB3aXRoaW4gdGhlIElFVEYuIA0KUmVhc29uYWJsZW5lc3MgZW50YWls cyBtZWV0aW5nIHRoZSBmb2xsb3dpbmcgY3JpdGVyaWE6DQoNCiAgKiByZXF1aXJlcyBzdGFuZGFy ZGl6YXRpb24gdG8gYmUgZWZmZWN0aXZlLA0KICAqIHRoZXJlIGlzIHNvbWUgZXZpZGVuY2UgdGhh dCBpdCB3b3VsZCwgaW4gZmFjdCwgaGF2ZSBhIGRlbW9uc3RyYWJsZQ0KICAgIGltcGFjdCBvbiB0 aGUgc3BpdCBwcm9ibGVtIGJhc2VkIG9uIGEgcGxhdXNpYmlsaXR5IHRocmVzaG9sZCANCiAgICBn aXZlbiBjZXJ0YWluIGFzc3VtcHRpb25zDQogICogaGFzIGEgc2NvcGUgb2YgYXBwbGljYWJpbGl0 eSB0aGF0IGlzIHN1ZmZpY2llbnRseSBicm9hZCB0byBiZQ0KICAgIHVzZWZ1bA0KDQpUbyB0aGF0 IGVuZCwgdGhpcyBleHBsb3JhdG9yeSBncm91cCBpcyBjaGFydGVyZWQgd2l0aCBkZXRlcm1pbmlu Zw0Kd2hldGhlciB0aGVyZSBhcmUgb25lIG9yIG1vcmUgbWVjaGFuaXNtcyBmb3IgcHJldmVudGlu ZyBTUElUIHdoaWNoDQp3b3VsZCBiZSByZWFzb25hYmxlIHN1YmplY3RzIGZvciBzdGFuZGFyZGl6 YXRpb24gd2l0aGluIHRoZSBJRVRGLCBhbmQNCmlmIHRoZXJlIGFyZSwgdG8gcHJvZHVjZSBhIGNo YXJ0ZXIgZm9yIGEgd29ya2luZyBncm91cCB0byBkZXZlbG9wDQpzdGFuZGFyZHMgZm9yIHN1Y2gg bWVjaGFuaXNtcy4NCg0KVG8gYWNoaWV2ZSB0aGVzZSBnb2FscywgdGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBzb2xpY2l0IGlucHV0cyAoaW4gdGhlDQpmb3JtIG9mIGluZGl2aWR1YWwgSW50ZXJuZXQg RHJhZnRzKSB3aGljaCBkbyB0aGUgZm9sbG93aW5nOg0KDQogIDEuIGRlc2NyaWJlIHRoZSBwcm9w b3NlZCBtZWNoYW5pc20gaW4gdGVybXMgb2YgaW5mb3JtYXRpb24gZmxvdywNCiAgaW5mb3JtYXRp b24gc2VtYW50aWNzLCBhbmQgaG93IHRoYXQgaW5mb3JtYXRpb24gaXMgdXNlZCwgYXQNCiAgc3Vm ZmljaWVudCBsZXZlbHMgb2YgZGV0YWlsIHRvIGFjaGlldmUgdGhlIHJlc3Qgb2YgdGhlIG9iamVj dGl2ZXMNCiAgYmVsb3cuIFByb3RvY29sIG1hY2hpbmVyeSAtIHN1Y2ggYXMgaGVhZGVycywgc3lu dGF4LCBhbmQgc28gb24gLSBhcmUNCiAgaXJyZWxldmFudCBhbmQgZGlzdHJhY3RpbmcuIEhvd2V2 ZXIsIHN1ZmZpY2llbnQgZGV0YWlsIG11c3QgYmUgZ2l2ZW4NCiAgc28gdGhhdCBpbXBsZW1lbnRp bmcgdGhlIG1lY2hhbmlzbSBpcyBhIG1hdHRlciBvZiBlbmdpbmVlcmluZyBhbmQNCiAgZGVzaWdu LCBhbmQgbm90ICdyZXNlYXJjaCcuIEZvciBleGFtcGxlLCBhIHByb3Bvc2FsIHdoaWNoIHJlbGll cyBvbg0KICBjb25zdWx0YXRpb24gb2YgYW4gJ29yYWNsZScsIHdpdGhvdXQgZGVzY3JpYmluZyBh dCBsZWFzdCBvbmUNCiAgbWVjaGFuaXNtIGJ5IHdoaWNoIGFuIG9yYWNsZSBtaWdodCBhbnN3ZXIg YSBxdWVzdGlvbiwgaXMgbm90DQogIHN1ZmZpY2llbnQuIEFzIGFub3RoZXIgZXhhbXBsZSwgYSBw cm9wb3NhbCB3aGljaCBwcm9wb3NlcyB0aGF0DQogIG1ldHJpY3MgYmUgcGFzc2VkIGFyb3VuZCB3 aXRob3V0IGRlc2NyaWJpbmcgZXhhbXBsZSBtZXRyaWNzIGFuZCBob3cNCiAgdGhleSBhcmUgY29t cHV0ZWQsIGlzIG5vdCBzdWZmaWNpZW50Lg0KDQogIEFzIGFuIGV4YW1wbGUsIGEgcHJvcG9zYWwg b24gJ3NwYW0gc2NvcmluZycgbWlnaHQgcHJvcG9zZTogIlRoZQ0KICBvcmlnaW5hdGluZyBkb21h aW4gb2YgYSBjYWxsIGxvb2sgYXQgdGhlIGNhbGxlcidzIHByb2ZpbGUsIGFuZCB0aGVuDQogIGNv bXB1dGUgdGhlIG51bWJlciBvZiBjYWxscyBwZXIgZGF5IGZvciB0aGF0IGNhbGxlciwgYW5kIGNv bXBhcmUgaXQNCiAgdG8gYXZlcmFnZS4gSXQgdGhlbiBjb25zaWRlcnMgdGhlIHJhdGlvIG9mIHRo ZXNlIHR3byBhcyBhbiBpbmRpY2F0b3INCiAgb2YgYSBwb3RlbnRpYWwgc3BhbW1lci4gVGhpcyBy YXRpbyBpcyB0aGVuIHNlbnQgaW4gdGhlIHNpZ25hbGluZw0KICBmcm9tIHRoZSBjYWxsaW5nIHRv IGNhbGxlZCBkb21haW4uIFRoZSBjYWxsZWQgZG9tYWluIGhhcyBhDQogIGNvbmZpZ3VyZWQgdGhy ZXNob2xkLCBhbmQgaWYgdGhlIHJhdGlvIGlzIGFib3ZlIGl0LCB0aGUgY2FsbCBpcw0KICBkaXNj YXJkZWQuIiBUaGlzIGlzIHRoZSBraW5kIG9mIGxldmVsIG9mIGRldGFpbCB0aGF0IGlzIG5lZWRl ZC4gDQoNCiAgMi4gZGVzY3JpYmUgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgZm9yIHRoZSBt ZWNoYW5pc20uIERvZXMgaXQNCiAgd29yayB3aXRoaW4gYSBkb21haW4gb25seT8gSW50ZXItZG9t YWluPyBSZXF1aXJlIHRydXN0IGZlZGVyYXRpb25zPw0KICBXb3JrIGluIGFuIGVudmlyb25tZW50 IHdoZXJlIG9ubHkgc29tZSBvZiB0aGUgc3lzdGVtcyBzdXBwb3J0IGl0Pw0KICBSZXF1aXJlIGNo YW5nZXMgaW4gY2xpZW50cz8gSW4gc2VydmVycz8gUmVxdWlyZSBjZW50cmFsaXplZCB0cnVzdA0K ICBhbmNob3JzPyBXb3JrIHdpdGggaHVtYW4tZ2VuZXJhdGVkIG9yIGJvdG5ldC1nZW5lcmF0ZWQg KHJlY29yZGVkKSANCiAgc3BhbT8gQW5kIHNvIG9uLg0KDQogIDMuIGNsZWFybHkgaW5kaWNhdGUg d2h5IHRoZSBhdXRob3Igb2YgdGhlIHByb3Bvc2FsIGJlbGlldmVzIHRoZQ0KICBtZWNoYW5pc20g d291bGQsIGluIGZhY3QsIGhhdmUgYSBkZW1vbnN0cmFibGUgaW1wYWN0IG9uIHJlZHVjaW5nDQog IHNwaXQuICJEZW1vbnN0cmFibGUiIG1lYW5zIHRoYXQsIGFuIGVuZ2luZWVyaW5nIGFyZ3VtZW50 IGNvdWxkIGJlDQogIG1hZGUgdGhhdCwgd2l0aGluIHRoZSBzY29wZSBvZiBhcHBsaWNhYmlsaXR5 LCB0aGVyZSBpcyBhIHF1YWxpdGF0aXZlDQogIG9yIHF1YW50aXRhdGl2ZSBhbmFseXNpcyB0aGF0 IHNob3dzIHRoYXQgdGhlIHZvbHVtZSBvZiBzcGl0IGNvdWxkIGJlDQogIHJlZHVjZWQuIFRoZSBw cm9wb3NhbCBzaG91bGQgcHJlLWVtcHRpdmVseSBjYXB0dXJlIGFyZ3VtZW50cyB0aGF0DQogIGNv dWxkIGJlIG1hZGUgYWdhaW5zdCB0aGUgcHJvcG9zYWwuIEZvciBleGFtcGxlLCBhIGhhc2hjYXNo IHByb3Bvc2FsDQogIG5lZWRzIHRvIGRpc2N1c3MgdGhlIGRpZmZlcmVuY2VzIGluIGNvbXB1dGF0 aW9uYWwgY2FwYWJpbGl0aWVzDQogIGJldHdlZW4gbGVnaXRpbWF0ZSBlbmRwb2ludHMgYW5kIGhv dyB0aG9zZSBkaWZmZXIgZnJvbSBzcGFtbWVycy4gSXQNCiAgaXMgYWNjZXB0YWJsZSBpZiB0aGUg cHJvcG9zYWwgZG9lc24ndCB3b3JrIHRoYXQgd2VsbCBpbiB0aGUgZmFjZSBvZiANCiAgYm90bmV0 cywgdGhvdWdoIHRoaXMgdG9waWMgc2hvdWxkIGJlIGRpc2N1c3NlZC4NCg0KICA0LiBjbGVhcmx5 IGluZGljYXRlIHdoeSBzdGFuZGFyZGl6YXRpb24gaXMgbmVlZGVkIHRvIG1ha2UgdGhlDQogIG1l Y2hhbmlzbSB3b3JrLiBBbnkgbWVjaGFuaXNtIHdoaWNoIHJlbGllcyBvbmx5IG9uIGxvY2FsIGNv bXB1dGF0aW9uDQogIHdpdGhpbiBhIGhvc3QgKGZvciBleGFtcGxlLCBsb29raW5nIGZvciBtYWxm b3JtZWQgU0lQIHJlcXVlc3RzKSBkb2VzDQogIG5vdCByZXF1aXJlIHN0YW5kYXJkaXphdGlvbi4N Cg0KDQpBdCBtaW5pbXVtIHRoZSBFRyBpcyBnb2luZyB0byBkaXNjdXNzOg0KDQogICAqIHNwYW0g c2NvcmluZw0KICAgKiByZXB1dGF0aW9uIHN5c3RlbXMNCiAgICogVHVyaW5nIHRlc3RzDQoNClRo ZXJlIGFyZSBwcm9wb3NhbHMgb24gdGhlIHRhYmxlIGFyb3VuZCB0aGVzZSBtZWNoYW5pc21zIHRo YXQgYXQgbGVhc3QNCnNvbWUgcG9ydGlvbiBvZiB0aGUgY29tbXVuaXR5IGJlbGlldmVzIHdvdWxk IGJlbmVmaXQgZnJvbQ0Kc3RhbmRhcmRpemF0aW9uLiBBdXRob3JzIG9mIHRob3NlIHByb3Bvc2Fs cyB3aWxsIHR1cm4gdGhlbSBpbnRvIHRoZQ0KZG9jdW1lbnRhdGlvbiBkZXNjcmliZWQgYWJvdmUu IFRoZSBncm91cCB3aWxsIGFkZGl0aW9uYWxseSBpc3N1ZSBhbg0Kb3BlbiBjYWxsIGZvciBhZGRp dGlvbmFsIGRvY3VtZW50YXRpb24uDQoNCldpdGggcHJvcG9zYWxzIG9uIHRoZSB0YWJsZSwgdGhl IEVHIHdpbGwgZGlzY3VzcyB0aGUgY29udGVudHMuIFRoZSBvbmUNCmFuZCBvbmx5IHB1cnBvc2Ug b2YgdGhhdCBkaXNjdXNzaW9uIGlzIHRvIG1ha2UgYW4gYXNzZXNzbWVudCBvbg0Kd2hldGhlciB0 aGVyZSBhcmUgb25lIG9yIG1vcmUgbWVjaGFuaXNtcyB3aGljaCBjb3VsZCBwbGF1c2libHkgaGF2 ZSBhbg0KaW1wYWN0IG9uIHJlZHVjaW5nIHVuc29saWNpdGVkIGNvbW11bmljYXRpb25zLCBhbmQg Zm9yIHdoaWNoIElFVEYgDQpzdGFuZGFyZGl6YXRpb24gd291bGQgYmUgYW4gYXBwcm9wcmlhdGUg YWN0aW9uLiBEaXNjdXNzaW9ucyBvbiBTSVAgDQpkZXRhaWxzLCBoZWFkZXJzIHZzLiBib2RpZXMs IGV4dGVuc2liaWxpdHkgbW9kZWxzLCBmcmFtZXdvcmtzLCANCnRlcm1pbm9sb2d5LCBhbmQgc28g b24sIHdvdWxkIGJlIG91dCBvZiBzY29wZSBmb3IgdGhlIEVHIGRpc2N1c3Npb24uIA0KVGhvc2Ug ZGlzY3Vzc2lvbnMgd291bGQgYmUgYXBwcm9wcmlhdGUgZm9yIGEgV0csIHNob3VsZCB0aGUgRUcg DQpkZWNpZGUgdG8gZm9ybSBvbmUuDQoNCg0KR29hbHMgYW5kIE1pbGVzdG9uZXM6DQoNCkF1ZyAy MDA4ICBGb3JtYXRpb24gb2YgYW4gZXhwbG9yYXRvcnkgd29ya2luZyBncm91cA0KU2VwIDIwMDgg IEluaXRpYWwgdmVyc2lvbnMgb2YgaGlnaC1sZXZlbCBtZWNoYW5pc20gcHJvcG9zYWxzIG1lZXRp bmcNCnRoZSBjcml0ZXJpYSBhYm92ZSwgc3VibWl0dGVkIGFzIGluZGl2aWR1YWwgSS1Ecw0KT2N0 L05vdiAyMDA4ICBQZXJpb2RpYyAod2Vla2x5IG9yIGJpd2Vla2x5KSB0ZWxlY29ucyB0byBkaXNj dXNzDQpOb3YgMjAwOCAgQ29udGludWUgZGlzY3Vzc2lvbnMgYXQgdGhlIElFVEYgbWVldGluZw0K RmViIDIwMDkgIEFncmVlIG9uIHdoZXRoZXIgdGhlcmUgc2hvdWxkIGJlIGFuIElFVEYgV0csIGFu ZCBpZiBzbywNCmFncmVlIG9uIGEgY2hhcnRlcg0KTWFyIDIwMDkgIENsb3NlIEVHDQoNCg== ------_=_NextPart_001_01C8F6DA.0247784F 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 ------_=_NextPart_001_01C8F6DA.0247784F-- From rucus-bounces@ietf.org Tue Aug 5 08:36:32 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C181028C280; Tue, 5 Aug 2008 08:36:32 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CBC28C286 for ; Tue, 5 Aug 2008 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPiBGY5Uk+dN for ; Tue, 5 Aug 2008 08:36:30 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BE2A228C25E for ; Tue, 5 Aug 2008 08:36:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2E2F42C01C955; Tue, 5 Aug 2008 17:37:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL7QJRrvO4fu; Tue, 5 Aug 2008 17:37:01 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 10ABF2C019185; Tue, 5 Aug 2008 17:36:51 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 17:36:51 +0200 Message-ID: <547F018265F92642B577B986577D671C22C282@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS Charter Text v1 Thread-Index: Acj22gQQLU5HeJK4QTKoTwZDPsJauQANvJaA References: From: "Saverio Niccolini" To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Subject: Re: [Rucus] RUCUS Charter Text v1 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 fully support this charter and hope to see the EG formed soon. Looking forward to work on this. Cheers, 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 Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, August 05, 2008 11:03 AM > To: rucus@ietf.org > Subject: [Rucus] RUCUS Charter Text v1 > > Hi all, > > As you might have noticed, we got stuck a bit with the > charter discussions on the list. Hence, a few of us, namely > Mary Barnes, Jonathan Rosenberg, Jon Peterson, Henning > Schulzrinne, Cullen Jennings and Jan Seedorf, used the IETF > 72 meeting to chat about the RUCUS charter. > > Jonathan, Henning and I came up with a first text proposal > based on the discussion we had during the meeting. Please > find it in the attachment. > > Please let us know whether you find the current charter text > acceptable. > > > Ciao > Hannes > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Aug 6 08:56:04 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 927673A6860; Wed, 6 Aug 2008 08:56:04 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EEA3A67DD for ; Wed, 6 Aug 2008 08:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] 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 UeNXgjByE8lI for ; Wed, 6 Aug 2008 08:56:01 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 57A773A6899 for ; Wed, 6 Aug 2008 08:56:00 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m76FuMoU024314; Wed, 6 Aug 2008 17:56:22 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 6 Aug 2008 17:56:22 +0200 Message-ID: <4899C9A0.3000509@alcatel-lucent.fr> Date: Wed, 06 Aug 2008 17:56:16 +0200 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: In-Reply-To: X-OriginalArrivalTime: 06 Aug 2008 15:56:22.0761 (UTC) FILETIME=[F94EB590:01C8F7DC] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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="===============0445550598==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a multi-part message in MIME format. --===============0445550598== Content-Type: multipart/alternative; boundary="------------080409050709040301050802" This is a multi-part message in MIME format. --------------080409050709040301050802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for putting this together, I fully support this charter, some minor comments inlines... > The Session Initiation Protocol (SIP) is an application-layer control > (signaling) protocol for creating, modifying, and terminating sessions > with one or more participants. These sessions include Internet > telephone calls, multimedia distribution, and multimedia > conferences. Like other communication protocols, SIP is susceptible to > unwanted communication attempts. RFC 5039 analyzes the problem of > spam in SIP and examines various possible solutions that have been > discussed for email and considers their applicability to SIP. > > RFC 5039 gives good, high-level recommendations regarding future work, > namely to provide > > * Strong Identity > * White Lists > > Should say probably: namely to: * Provide strong Identity * Provide White Lists * Solve the Introduction Problem * Don't Wait Until It's Too Late > Among the many individual mechanisms that are discussed in RFC > 5039 (including content filtering, black lists, white lists, > consent-based communication, reputation systems, address obfuscation, > limited use addresses, turing tests, computational puzzles, payments > at risk, circles of trust, and many others) there is no clear guidance > on whether one of the mechanisms listed - or something else entirely - > is subject of additional standards work. > > Furthermore, since the publication of RFC 5039, many documents have > been submitted to IETF which define frameworks, propose protocol > headers, or document additional guidelines on techniques in RFC > 5039. These documents include: > > * draft-wing-sipping-spam-score > * draft-jennings-sip-hashcash > * draft-tschofenig-sipping-spit-policy > should'nt we mention draft-froment-sipping-spit-requirements since it comes with spit-policy? > * draft-tschofenig-sipping-captcha > * draft-niccolini-sipping-feedback-spit > > Despite the plethora of documents, there is debate in the community > over whether there would be any value in pursuing any or all of > these. > > The purpose of this exploratory group is to determine whether there > are one or more mechanisms for mitigation of unsoicited communication, > unsoicited --> unsolicited > which would be reasonable subjects for standardization within the IETF. > Reasonableness entails meeting the following criteria: > > * requires standardization to be effective, > * there is some evidence that it would, in fact, have a demonstrable > impact on the spit problem based on a plausibility threshold > given certain assumptions > * has a scope of applicability that is sufficiently broad to be > useful > > To that end, this exploratory group is chartered with determining > whether there are one or more mechanisms for preventing SPIT which > would be reasonable subjects for standardization within the IETF, and > if there are, to produce a charter for a working group to develop > standards for such mechanisms. > > To achieve these goals, the working group will solicit inputs (in the > form of individual Internet Drafts) which do the following: > > 1. describe the proposed mechanism in terms of information flow, > information semantics, and how that information is used, at > sufficient levels of detail to achieve the rest of the objectives > below. Protocol machinery - such as headers, syntax, and so on - are > irrelevant and distracting. However, sufficient detail must be given > so that implementing the mechanism is a matter of engineering and > design, and not 'research'. For example, a proposal which relies on > consultation of an 'oracle', without describing at least one > mechanism by which an oracle might answer a question, is not > sufficient. As another example, a proposal which proposes that > metrics be passed around without describing example metrics and how > they are computed, is not sufficient. > > As an example, a proposal on 'spam scoring' might propose: "The > originating domain of a call look at the caller's profile, and then > compute the number of calls per day for that caller, and compare it > to average. It then considers the ratio of these two as an indicator > of a potential spammer. This ratio is then sent in the signaling > from the calling to called domain. The called domain has a > configured threshold, and if the ratio is above it, the call is > discarded." This is the kind of level of detail that is needed. > > 2. describe the scope of applicability for the mechanism. Does it > work within a domain only? Inter-domain? Require trust federations? > Work in an environment where only some of the systems support it? > Require changes in clients? In servers? Require centralized trust > anchors? Work with human-generated or botnet-generated (recorded) > spam? And so on. > > 3. clearly indicate why the author of the proposal believes the > mechanism would, in fact, have a demonstrable impact on reducing > spit. "Demonstrable" means that, an engineering argument could be > made that, within the scope of applicability, there is a qualitative > or quantitative analysis that shows that the volume of spit could be > reduced. The proposal should pre-emptively capture arguments that > could be made against the proposal. For example, a hashcash proposal > needs to discuss the differences in computational capabilities > between legitimate endpoints and how those differ from spammers. It > is acceptable if the proposal doesn't work that well in the face of > botnets, though this topic should be discussed. > > 4. clearly indicate why standardization is needed to make the > mechanism work. Any mechanism which relies only on local computation > within a host (for example, looking for malformed SIP requests) does > not require standardization. > > > At minimum the EG is going to discuss: > > * spam scoring > * reputation systems > * Turing tests > > There are proposals on the table around these mechanisms that at least > some portion of the community believes would benefit from > standardization. Authors of those proposals will turn them into the > documentation described above. The group will additionally issue an > open call for additional documentation. > > With proposals on the table, the EG will discuss the contents. The one > and only purpose of that discussion is to make an assessment on > whether there are one or more mechanisms which could plausibly have an > impact on reducing unsolicited communications, and for which IETF > standardization would be an appropriate action. Discussions on SIP > details, headers vs. bodies, extensibility models, frameworks, > terminology, and so on, would be out of scope for the EG discussion. > Those discussions would be appropriate for a WG, should the EG > decide to form one. > > > Goals and Milestones: > > Aug 2008 Formation of an exploratory working group > Sep 2008 Initial versions of high-level mechanism proposals meeting > the criteria above, submitted as individual I-Ds > The deadline of Sep 2008 seems to be very short to submit these individual IDs, but well... > Oct/Nov 2008 Periodic (weekly or biweekly) telecons to discuss > Nov 2008 Continue discussions at the IETF meeting > Feb 2009 Agree on whether there should be an IETF WG, and if so, > agree on a charter > Mar 2009 Close EG Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi all, > > As you might have noticed, we got stuck a bit with the charter > discussions on the list. Hence, a few of us, namely Mary Barnes, > Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, Cullen Jennings > and Jan Seedorf, used the IETF 72 meeting to chat about the RUCUS > charter. > > Jonathan, Henning and I came up with a first text proposal based on the > discussion we had during the meeting. Please find it in the attachment. > > Please let us know whether you find the current charter text acceptable. > > > Ciao > Hannes > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus --------------080409050709040301050802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Thanks for putting this together, I fully support this charter,

some minor comments inlines...

The Session Initiation Protocol (SIP) is an application-layer control
(signaling) protocol for creating, modifying, and terminating sessions
with one or more participants.  These sessions include Internet
telephone calls, multimedia distribution, and multimedia
conferences. Like other communication protocols, SIP is susceptible to
unwanted communication attempts.  RFC 5039 analyzes the problem of
spam in SIP and examines various possible solutions that have been
discussed for email and considers their applicability to SIP.

RFC 5039 gives good, high-level recommendations regarding future work,
namely to provide

* Strong Identity
* White Lists
Should say probably:
namely to:
* Provide strong Identity
* Provide White Lists
* Solve the Introduction Problem
* Don't Wait Until It's Too Late


Among the many individual mechanisms that are discussed in RFC
5039 (including content filtering, black lists, white lists,
consent-based communication, reputation systems, address obfuscation,
limited use addresses, turing tests, computational puzzles, payments
at risk, circles of trust, and many others) there is no clear guidance
on whether one of the mechanisms listed - or something else entirely -
is subject of additional standards work. 

Furthermore, since the publication of RFC 5039, many documents have
been submitted to IETF which define frameworks, propose protocol
headers, or document additional guidelines on techniques in RFC
5039. These documents include:

* draft-wing-sipping-spam-score 
* draft-jennings-sip-hashcash 
* draft-tschofenig-sipping-spit-policy
should'nt we mention draft-froment-sipping-spit-requirements since it comes with spit-policy? 
* draft-tschofenig-sipping-captcha 
* draft-niccolini-sipping-feedback-spit

Despite the plethora of documents, there is debate in the community
over whether there would be any value in pursuing any or all of
these. 

The purpose of this exploratory group is to determine whether there
are one or more mechanisms for mitigation of unsoicited communication, 
  
unsoicited --> unsolicited
which would be reasonable subjects for standardization within the IETF. 
Reasonableness entails meeting the following criteria:

  * requires standardization to be effective,
  * there is some evidence that it would, in fact, have a demonstrable
    impact on the spit problem based on a plausibility threshold 
    given certain assumptions
  * has a scope of applicability that is sufficiently broad to be
    useful

To that end, this exploratory group is chartered with determining
whether there are one or more mechanisms for preventing SPIT which
would be reasonable subjects for standardization within the IETF, and
if there are, to produce a charter for a working group to develop
standards for such mechanisms.

To achieve these goals, the working group will solicit inputs (in the
form of individual Internet Drafts) which do the following:

  1. describe the proposed mechanism in terms of information flow,
  information semantics, and how that information is used, at
  sufficient levels of detail to achieve the rest of the objectives
  below. Protocol machinery - such as headers, syntax, and so on - are
  irrelevant and distracting. However, sufficient detail must be given
  so that implementing the mechanism is a matter of engineering and
  design, and not 'research'. For example, a proposal which relies on
  consultation of an 'oracle', without describing at least one
  mechanism by which an oracle might answer a question, is not
  sufficient. As another example, a proposal which proposes that
  metrics be passed around without describing example metrics and how
  they are computed, is not sufficient.

  As an example, a proposal on 'spam scoring' might propose: "The
  originating domain of a call look at the caller's profile, and then
  compute the number of calls per day for that caller, and compare it
  to average. It then considers the ratio of these two as an indicator
  of a potential spammer. This ratio is then sent in the signaling
  from the calling to called domain. The called domain has a
  configured threshold, and if the ratio is above it, the call is
  discarded." This is the kind of level of detail that is needed. 

  2. describe the scope of applicability for the mechanism. Does it
  work within a domain only? Inter-domain? Require trust federations?
  Work in an environment where only some of the systems support it?
  Require changes in clients? In servers? Require centralized trust
  anchors? Work with human-generated or botnet-generated (recorded) 
  spam? And so on.

  3. clearly indicate why the author of the proposal believes the
  mechanism would, in fact, have a demonstrable impact on reducing
  spit. "Demonstrable" means that, an engineering argument could be
  made that, within the scope of applicability, there is a qualitative
  or quantitative analysis that shows that the volume of spit could be
  reduced. The proposal should pre-emptively capture arguments that
  could be made against the proposal. For example, a hashcash proposal
  needs to discuss the differences in computational capabilities
  between legitimate endpoints and how those differ from spammers. It
  is acceptable if the proposal doesn't work that well in the face of 
  botnets, though this topic should be discussed.

  4. clearly indicate why standardization is needed to make the
  mechanism work. Any mechanism which relies only on local computation
  within a host (for example, looking for malformed SIP requests) does
  not require standardization.


At minimum the EG is going to discuss:

   * spam scoring
   * reputation systems
   * Turing tests

There are proposals on the table around these mechanisms that at least
some portion of the community believes would benefit from
standardization. Authors of those proposals will turn them into the
documentation described above. The group will additionally issue an
open call for additional documentation.

With proposals on the table, the EG will discuss the contents. The one
and only purpose of that discussion is to make an assessment on
whether there are one or more mechanisms which could plausibly have an
impact on reducing unsolicited communications, and for which IETF 
standardization would be an appropriate action. Discussions on SIP 
details, headers vs. bodies, extensibility models, frameworks, 
terminology, and so on, would be out of scope for the EG discussion. 
Those discussions would be appropriate for a WG, should the EG 
decide to form one.


Goals and Milestones:

Aug 2008  Formation of an exploratory working group
Sep 2008  Initial versions of high-level mechanism proposals meeting
the criteria above, submitted as individual I-Ds
The deadline of Sep 2008 seems to be very short to submit these individual IDs, but well...
Oct/Nov 2008  Periodic (weekly or biweekly) telecons to discuss
Nov 2008  Continue discussions at the IETF meeting
Feb 2009  Agree on whether there should be an IETF WG, and if so,
agree on a charter
Mar 2009  Close EG

Tschofenig, Hannes (NSN - FI/Espoo) wrote: 
Hi all, 

As you might have noticed, we got stuck a bit with the charter
discussions on the list. Hence, a few of us, namely Mary Barnes,
Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, Cullen Jennings
and Jan Seedorf, used the IETF 72 meeting to chat about the RUCUS
charter. 

Jonathan, Henning and I came up with a first text proposal based on the
discussion we had during the meeting. Please find it in the attachment. 

Please let us know whether you find the current charter text acceptable.


Ciao
Hannes

  

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

--------------080409050709040301050802-- --===============0445550598== 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 --===============0445550598==-- From rucus-bounces@ietf.org Wed Aug 6 12:00: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 BB0B828C3BC; Wed, 6 Aug 2008 12:00:30 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBBA28C3BB for ; Wed, 6 Aug 2008 12:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 7Qro5yo4rwzj for ; Wed, 6 Aug 2008 12:00:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 513C928C409 for ; Wed, 6 Aug 2008 12:00:13 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5DB832081A; Wed, 6 Aug 2008 21:00:40 +0200 (CEST) X-AuditID: c1b4fb3c-ac0cabb0000015b5-9e-4899f4d89545 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 42F3B207A9; Wed, 6 Aug 2008 21:00:40 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Aug 2008 21:00:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 20:58:20 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS Charter Text v1 Thread-Index: Acj22gQQLU5HeJK4QTKoTwZDPsJauQBGPEJA References: From: "Michael Liljenstam" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 06 Aug 2008 19:00:40.0228 (UTC) FILETIME=[B8124640:01C8F7F6] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Rucus] RUCUS Charter Text v1 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, IMHO it looks good, and I also support it. I'd just like to ask a clarifying question: I noted that whitelists (recommended in RFC 5039) were not mentioned among the 3 mechanisms brought forward as the primary ones to be discussed. The charter text doesn't rule it out, of course. However, I'd be interested in knowing a bit about how the reasoning went around this. That is, it would be useful to know if it was not listed because 1) point implementation plausible which doesn't require standardization, 2) lower priority (or less to discuss?) than the 3 listed, 3) implicitly assumed and the focus here is on solving the introduction problem, or something else? Any comments? Thanks, Michael --- Michael Liljenstam Senior Research Engineer, Communications Security, Ericsson Research Phone: +46-8-404 4602, Email: michael.liljenstam@ericsson.com > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: den 5 augusti 2008 11:03 > To: rucus@ietf.org > Subject: [Rucus] RUCUS Charter Text v1 > > Hi all, > > As you might have noticed, we got stuck a bit with the > charter discussions on the list. Hence, a few of us, namely > Mary Barnes, Jonathan Rosenberg, Jon Peterson, Henning > Schulzrinne, Cullen Jennings and Jan Seedorf, used the IETF > 72 meeting to chat about the RUCUS charter. > > Jonathan, Henning and I came up with a first text proposal > based on the discussion we had during the meeting. Please > find it in the attachment. > > Please let us know whether you find the current charter text > acceptable. > > > Ciao > Hannes > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Aug 7 06:38:31 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 8E2613A6BF9; Thu, 7 Aug 2008 06:38:31 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF41B3A6BF9 for ; Thu, 7 Aug 2008 06:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4H9DbNNQgM9 for ; Thu, 7 Aug 2008 06:38:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9D1203A6AFD for ; Thu, 7 Aug 2008 06:38:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 212A02C0004E2; Thu, 7 Aug 2008 15:38:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsrcikGHRhh5; Thu, 7 Aug 2008 15:38:32 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id E85402C000352; Thu, 7 Aug 2008 15:38:16 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 15:38:10 +0200 Message-ID: <547F018265F92642B577B986577D671C22C436@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS Charter Text v1 Thread-Index: Acj22gQQLU5HeJK4QTKoTwZDPsJauQBGPEJAACfMv2A= References: From: "Saverio Niccolini" To: "Michael Liljenstam" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Subject: Re: [Rucus] RUCUS Charter Text v1 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 Michael, I think whitelists are fundamental in fighting unsolicited communications but "whitelists" as such are not really subject of standardization. Unless you want to standardize a method to share whitelists among users/domains, in that case you need protocols interoperability and there is whre you need standards. I think the charter simply implies what I have wrote above. Am I right Hannes? If this is not what you meant, sorry for misunderstanding your mail. Cheers, 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 Michael Liljenstam > Sent: Wednesday, August 06, 2008 8:58 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); rucus@ietf.org > Subject: Re: [Rucus] RUCUS Charter Text v1 > > Hi, > > IMHO it looks good, and I also support it. > > I'd just like to ask a clarifying question: I noted that > whitelists (recommended in RFC 5039) were not mentioned among > the 3 mechanisms brought forward as the primary ones to be > discussed. The charter text doesn't rule it out, of course. > However, I'd be interested in knowing a bit about how the > reasoning went around this. That is, it would be useful to > know if it was not listed because 1) point implementation > plausible which doesn't require standardization, 2) lower > priority (or less to discuss?) than the 3 listed, 3) > implicitly assumed and the focus here is on solving the > introduction problem, or something else? > > Any comments? > > Thanks, > Michael > --- > Michael Liljenstam > Senior Research Engineer, Communications Security, Ericsson Research > Phone: +46-8-404 4602, Email: michael.liljenstam@ericsson.com > > > > -----Original Message----- > > From: rucus-bounces@ietf.org > [mailto:rucus-bounces@ietf.org] On Behalf > > Of Tschofenig, Hannes (NSN - FI/Espoo) > > Sent: den 5 augusti 2008 11:03 > > To: rucus@ietf.org > > Subject: [Rucus] RUCUS Charter Text v1 > > > > Hi all, > > > > As you might have noticed, we got stuck a bit with the charter > > discussions on the list. Hence, a few of us, namely Mary Barnes, > > Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, > Cullen Jennings > > and Jan Seedorf, used the IETF > > 72 meeting to chat about the RUCUS charter. > > > > Jonathan, Henning and I came up with a first text proposal based on > > the discussion we had during the meeting. Please find it in the > > attachment. > > > > Please let us know whether you find the current charter text > > acceptable. > > > > > > 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 Thu Aug 7 06:51:50 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 C9CF128C179; Thu, 7 Aug 2008 06:51:50 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB6E28C179 for ; Thu, 7 Aug 2008 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=2.009, 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 H8e2D-2jDqoO for ; Thu, 7 Aug 2008 06:51:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 335983A67EB for ; Thu, 7 Aug 2008 06:51:47 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2008 13:51:41 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp059) with SMTP; 07 Aug 2008 15:51:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Mo6hacLzMS27UZhJ0yf/SirQNQtdJFDnq+bS5ab XSjaWWGR4X8Nb1 Message-ID: <489AFDCD.9090009@gmx.net> Date: Thu, 07 Aug 2008 16:51:09 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Michael Liljenstam References: In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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 Thanks for your feedback, Michael. We just forgot about it while writing the text. I added it. Michael Liljenstam wrote: > Hi, > > IMHO it looks good, and I also support it. > > I'd just like to ask a clarifying question: I noted that whitelists > (recommended in RFC 5039) were not mentioned among the 3 mechanisms > brought forward as the primary ones to be discussed. The charter text > doesn't rule it out, of course. However, I'd be interested in knowing a > bit about how the reasoning went around this. That is, it would be > useful to know if it was not listed because 1) point implementation > plausible which doesn't require standardization, That's certainly true although we have worked on standardized authorization policies in the IETF, such Presence Authorization Policies XMPP also has standardized authorization policies. > 2) lower priority (or > less to discuss?) than the 3 listed, Not really. Many of us would agree that it is a quite useful mechanism. It is probably less "exciting" to discuss compared to some other mechanisms. > 3) implicitly assumed and the focus > here is on solving the introduction problem, or something else? > > The introduction problem for certain communication patters are indeed challenging. Ciao Hannes > Any comments? > > Thanks, > Michael > --- > Michael Liljenstam > Senior Research Engineer, Communications Security, Ericsson Research > Phone: +46-8-404 4602, Email: michael.liljenstam@ericsson.com > > > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: den 5 augusti 2008 11:03 >> To: rucus@ietf.org >> Subject: [Rucus] RUCUS Charter Text v1 >> >> Hi all, >> >> As you might have noticed, we got stuck a bit with the >> charter discussions on the list. Hence, a few of us, namely >> Mary Barnes, Jonathan Rosenberg, Jon Peterson, Henning >> Schulzrinne, Cullen Jennings and Jan Seedorf, used the IETF >> 72 meeting to chat about the RUCUS charter. >> >> Jonathan, Henning and I came up with a first text proposal >> based on the discussion we had during the meeting. Please >> find it in the attachment. >> >> Please let us know whether you find the current charter text >> acceptable. >> >> >> 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 Thu Aug 7 06:57:36 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4527D3A6992; Thu, 7 Aug 2008 06:57:36 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5D43A6992 for ; Thu, 7 Aug 2008 06:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=1.507, 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 m068RW7WAwyE for ; Thu, 7 Aug 2008 06:57:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F2B543A68FB for ; Thu, 7 Aug 2008 06:57:33 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2008 13:58:09 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp059) with SMTP; 07 Aug 2008 15:58:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19eapJjxL5eCon1ByxvBlHoQIKB5HJoIgCqx4NqbN wZzUTuJFixhS+K Message-ID: <489AFF52.9090009@gmx.net> Date: Thu, 07 Aug 2008 16:57:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Saverio Niccolini References: <547F018265F92642B577B986577D671C22C436@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C22C436@VENUS.office> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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 A quick comment. Saverio Niccolini wrote: > Dear Michael, > > I think whitelists are fundamental in fighting unsolicited > communications but "whitelists" as such are not really subject > of standardization. > > There are two forms of white lists: * White lists created by users * White lists created by VoIP providers The former have been standardized in the IETF, see http://www.ietf.org/rfc/rfc4745.txt (Common Policy) http://www.ietf.org/rfc/rfc5025.txt (Presence Authorization Rules; using Common Policy) Similar mechanisms are availabe in XMPP: http://www.xmpp.org/extensions/xep-0016.html The later do not require a standardized mechanism since they are executed locally and will rarely change. > Unless you want to standardize a method to share whitelists among > users/domains, in that case you need protocols interoperability and > there is whre you need standards. > An interoperable mechanism is needed when you create the rules in one place and store (and execute them) at an other place. This is useful when you have multiple devices, when actions are supposed to be enforced at a node other than the end point, when multiple parties contribute to the rules. > I think the charter simply implies what I have wrote above. Am I > right Hannes? > > If this is not what you meant, sorry for misunderstanding your mail. > > Ciao Hannes > Cheers, > 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 Michael Liljenstam >> Sent: Wednesday, August 06, 2008 8:58 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); rucus@ietf.org >> Subject: Re: [Rucus] RUCUS Charter Text v1 >> >> Hi, >> >> IMHO it looks good, and I also support it. >> >> I'd just like to ask a clarifying question: I noted that >> whitelists (recommended in RFC 5039) were not mentioned among >> the 3 mechanisms brought forward as the primary ones to be >> discussed. The charter text doesn't rule it out, of course. >> However, I'd be interested in knowing a bit about how the >> reasoning went around this. That is, it would be useful to >> know if it was not listed because 1) point implementation >> plausible which doesn't require standardization, 2) lower >> priority (or less to discuss?) than the 3 listed, 3) >> implicitly assumed and the focus here is on solving the >> introduction problem, or something else? >> >> Any comments? >> >> Thanks, >> Michael >> --- >> Michael Liljenstam >> Senior Research Engineer, Communications Security, Ericsson Research >> Phone: +46-8-404 4602, Email: michael.liljenstam@ericsson.com >> >> >> >>> -----Original Message----- >>> From: rucus-bounces@ietf.org >>> >> [mailto:rucus-bounces@ietf.org] On Behalf >> >>> Of Tschofenig, Hannes (NSN - FI/Espoo) >>> Sent: den 5 augusti 2008 11:03 >>> To: rucus@ietf.org >>> Subject: [Rucus] RUCUS Charter Text v1 >>> >>> Hi all, >>> >>> As you might have noticed, we got stuck a bit with the charter >>> discussions on the list. Hence, a few of us, namely Mary Barnes, >>> Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, >>> >> Cullen Jennings >> >>> and Jan Seedorf, used the IETF >>> 72 meeting to chat about the RUCUS charter. >>> >>> Jonathan, Henning and I came up with a first text proposal based on >>> the discussion we had during the meeting. Please find it in the >>> attachment. >>> >>> Please let us know whether you find the current charter text >>> acceptable. >>> >>> >>> 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 Thu Aug 7 07:27:52 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 D2DFE3A6BEC; Thu, 7 Aug 2008 07:27:52 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767873A6BEC for ; Thu, 7 Aug 2008 07:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NECalnrYtugd for ; Thu, 7 Aug 2008 07:27:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E80C23A69F0 for ; Thu, 7 Aug 2008 07:27:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,320,1215388800"; d="scan'208";a="16773509" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 07 Aug 2008 14:27:57 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m77ERv9Q028066; Thu, 7 Aug 2008 10:27:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m77ERviI000772; Thu, 7 Aug 2008 14:27:57 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 10:27:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 10:27:20 -0400 Message-ID: In-Reply-To: <489AFF52.9090009@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS Charter Text v1 Thread-Index: Acj4la+k8iPcY1cuReqSMNDHH68JLgAA1eFg From: "Sanjay Sinha (sanjsinh)" To: "Hannes Tschofenig" , "Saverio Niccolini" X-OriginalArrivalTime: 07 Aug 2008 14:27:56.0806 (UTC) FILETIME=[C91FFA60:01C8F899] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5989; t=1218119277; x=1218983277; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[Rucus]=20RUCUS=20Charter=20Text=20v1 |Sender:=20 |To:=20=22Hannes=20Tschofenig=22=20,=0A=20=20=20=20=20=20=20=20=22Saverio=20Niccolini=22=20< Saverio.Niccolini@nw.neclab.eu>; bh=bMfU9WqnriGzM9GXNrRrgtmYWGQ6xsra4xuKH64LjV0=; b=GiSFX/5QJBiNJ6/hqbyMPgCxhc9iVkhPrGI3RoLi/DtVA+aVnpz7gpekkG ivvj5LTOrZoTgMmarJVJAFNLfNFXAHvDoSW0MGyqR+jLyxIAJUlADoUVrQwd p0dmQlJ9gq; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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 Pl. see inline .. >-----Original Message----- >From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: Thursday, August 07, 2008 9:58 AM >To: Saverio Niccolini >Cc: rucus@ietf.org >Subject: Re: [Rucus] RUCUS Charter Text v1 > >A quick comment. > > >Saverio Niccolini wrote: >> Dear Michael, >> >> I think whitelists are fundamental in fighting unsolicited >> communications but "whitelists" as such are not really subject of >> standardization. >> >> > >There are two forms of white lists: > >* White lists created by users >* White lists created by VoIP providers > >The former have been standardized in the IETF, see >http://www.ietf.org/rfc/rfc4745.txt (Common Policy) >http://www.ietf.org/rfc/rfc5025.txt (Presence Authorization >Rules; using Common Policy) > >Similar mechanisms are availabe in XMPP: >http://www.xmpp.org/extensions/xep-0016.html > >The later do not require a standardized mechanism since they >are executed locally and will rarely change. > >> Unless you want to standardize a method to share whitelists among >> users/domains, in that case you need protocols interoperability and >> there is whre you need standards. >> >An interoperable mechanism is needed when you create the rules >in one place and store (and execute them) at an other place. >This is useful when you have multiple devices, when actions >are supposed to be enforced at a node other than the end >point, when multiple parties contribute to the rules. Rule sharing is also needed for things like intradomain federation, esp. the union model, where user creates rules on one server and a mechanism is needed to sync them to the other federating servers as well, so that user does not need to recreate the rules on the other server, or have conflicting rules on different servers. Other mechanism is where there is a central datastore for the rules, in that case also a mechanism is needed to share rules from the node it is created on to the central datastore. Sanjay > >> I think the charter simply implies what I have wrote above. >Am I right >> Hannes? >> >> If this is not what you meant, sorry for misunderstanding your mail. >> >> >Ciao >Hannes > >> Cheers, >> 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 Michael Liljenstam >>> Sent: Wednesday, August 06, 2008 8:58 PM >>> To: Tschofenig, Hannes (NSN - FI/Espoo); rucus@ietf.org >>> Subject: Re: [Rucus] RUCUS Charter Text v1 >>> >>> Hi, >>> >>> IMHO it looks good, and I also support it. >>> >>> I'd just like to ask a clarifying question: I noted that whitelists >>> (recommended in RFC 5039) were not mentioned among the 3 mechanisms >>> brought forward as the primary ones to be discussed. The >charter text >>> doesn't rule it out, of course. >>> However, I'd be interested in knowing a bit about how the reasoning >>> went around this. That is, it would be useful to know if it was not >>> listed because 1) point implementation plausible which doesn't >>> require standardization, 2) lower priority (or less to >discuss?) than >>> the 3 listed, 3) implicitly assumed and the focus here is >on solving >>> the introduction problem, or something else? >>> >>> Any comments? >>> >>> Thanks, >>> Michael >>> --- >>> Michael Liljenstam >>> Senior Research Engineer, Communications Security, Ericsson Research >>> Phone: +46-8-404 4602, Email: michael.liljenstam@ericsson.com >>> >>> >>> >>>> -----Original Message----- >>>> From: rucus-bounces@ietf.org >>>> >>> [mailto:rucus-bounces@ietf.org] On Behalf >>> >>>> Of Tschofenig, Hannes (NSN - FI/Espoo) >>>> Sent: den 5 augusti 2008 11:03 >>>> To: rucus@ietf.org >>>> Subject: [Rucus] RUCUS Charter Text v1 >>>> >>>> Hi all, >>>> >>>> As you might have noticed, we got stuck a bit with the charter >>>> discussions on the list. Hence, a few of us, namely Mary Barnes, >>>> Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, >>>> >>> Cullen Jennings >>> >>>> and Jan Seedorf, used the IETF >>>> 72 meeting to chat about the RUCUS charter. >>>> >>>> Jonathan, Henning and I came up with a first text proposal >based on >>>> the discussion we had during the meeting. Please find it in the >>>> attachment. >>>> >>>> Please let us know whether you find the current charter text >>>> acceptable. >>>> >>>> >>>> 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 > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Aug 7 08:14:49 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839F828C1AF; Thu, 7 Aug 2008 08:14:49 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB103A6AE6 for ; Thu, 7 Aug 2008 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGgWJZvktS3t for ; Thu, 7 Aug 2008 08:14:47 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2FCBD3A69C7 for ; Thu, 7 Aug 2008 08:14:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,320,1215388800"; d="scan'208";a="16800884" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Aug 2008 15:14:48 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m77FEmXr025458; Thu, 7 Aug 2008 11:14:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m77FEmOf010527; Thu, 7 Aug 2008 15:14:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 11:14:48 -0400 Received: from [10.82.209.15] ([10.82.209.15]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 11:14:47 -0400 Message-ID: <489B1171.2050101@cisco.com> Date: Thu, 07 Aug 2008 11:14:57 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael Liljenstam References: In-Reply-To: X-OriginalArrivalTime: 07 Aug 2008 15:14:48.0039 (UTC) FILETIME=[54C01770:01C8F8A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2579; t=1218122088; x=1218986088; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Rucus]=20RUCUS=20Charter=20Text=20v1 |Sender:=20 |To:=20Michael=20Liljenstam=20; bh=m5fHdEfYToiWm0vZOb81vIyuBI1XT4GAda/AIQXl7Ok=; b=UURPZwB2keTNL240C7Y25NaT73SfcazdCIQyDUjZ4e4G8QULXO0ZfYpBy7 Xs7aNMVC1lv0X71hx4t+pV8CAGKy0DjldXc2H6HXxb4vb8T6IiDUSDpUzuln pR38SxAmvW; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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 The charter in no way constrains what ideas people can bring to the table. Its there mainly to just help us define what it is we need to do over the next few months. Its much less important to wordsmith the charter than it is for folks to start writing up their drafts that follow the basic principles defined in it. -Jonathan R. Michael Liljenstam wrote: > Hi, > > IMHO it looks good, and I also support it. > > I'd just like to ask a clarifying question: I noted that whitelists > (recommended in RFC 5039) were not mentioned among the 3 mechanisms > brought forward as the primary ones to be discussed. The charter text > doesn't rule it out, of course. However, I'd be interested in knowing a > bit about how the reasoning went around this. That is, it would be > useful to know if it was not listed because 1) point implementation > plausible which doesn't require standardization, 2) lower priority (or > less to discuss?) than the 3 listed, 3) implicitly assumed and the focus > here is on solving the introduction problem, or something else? > > Any comments? > > Thanks, > Michael > --- > Michael Liljenstam > Senior Research Engineer, Communications Security, Ericsson Research > Phone: +46-8-404 4602, Email: michael.liljenstam@ericsson.com > > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) >> Sent: den 5 augusti 2008 11:03 >> To: rucus@ietf.org >> Subject: [Rucus] RUCUS Charter Text v1 >> >> Hi all, >> >> As you might have noticed, we got stuck a bit with the >> charter discussions on the list. Hence, a few of us, namely >> Mary Barnes, Jonathan Rosenberg, Jon Peterson, Henning >> Schulzrinne, Cullen Jennings and Jan Seedorf, used the IETF >> 72 meeting to chat about the RUCUS charter. >> >> Jonathan, Henning and I came up with a first text proposal >> based on the discussion we had during the meeting. Please >> find it in the attachment. >> >> Please let us know whether you find the current charter text >> acceptable. >> >> >> Ciao >> Hannes >> >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sun Aug 10 13:13:12 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 1BBC23A696A; Sun, 10 Aug 2008 13:13:12 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F76D3A696A for ; Sun, 10 Aug 2008 13:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.88 X-Spam-Level: *** X-Spam-Status: No, score=3.88 tagged_above=-999 required=5 tests=[AWL=6.479, 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 1SulgYdZrbvL for ; Sun, 10 Aug 2008 13:13:10 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D8B0C3A67D8 for ; Sun, 10 Aug 2008 13:13:05 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2008 20:13:06 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp025) with SMTP; 10 Aug 2008 22:13:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/cyJ41WfvcAIcvB5Mx2Wx0rE2ECEAOWewODFVTmy EWjhNovIneoyb8 Message-ID: <489F4BD5.7030302@gmx.net> Date: Sun, 10 Aug 2008 23:13:09 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" References: In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8100000000000001 Cc: rucus@ietf.org, Saverio Niccolini Subject: Re: [Rucus] RUCUS Charter Text v1 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 > Rule sharing is also needed for things like intradomain federation, esp. > the union model, where user creates rules on one server and a mechanism > is needed to sync them to the other federating servers as well, so that > user does not need to recreate the rules on the other server, or have > conflicting rules on different servers. > Other mechanism is where there is a central datastore for the rules, in > that case also a mechanism is needed to share rules from the node it is > created on to the central datastore. > > Sanjay > > Thanks for pointing to rule sharing. I guess you refer to http://www.ietf.org/internet-drafts/draft-ietf-simple-view-sharing-01.txt Right? _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sun Aug 10 13:13:22 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 345343A696A; Sun, 10 Aug 2008 13:13:22 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BDC3A6817 for ; Sun, 10 Aug 2008 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.64 X-Spam-Level: X-Spam-Status: No, score=0.64 tagged_above=-999 required=5 tests=[AWL=3.239, 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 0L1G22BdORXS for ; Sun, 10 Aug 2008 13:13:19 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1032A3A696A for ; Sun, 10 Aug 2008 13:13:18 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2008 20:13:20 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp016) with SMTP; 10 Aug 2008 22:13:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9WxJDP029B/1SSvWewy0l8N7rnBBURbeXYMWeOV fHXnUA33uW6ZAN Message-ID: <489F4BE5.3060606@gmx.net> Date: Sun, 10 Aug 2008 23:13:25 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: rucus@ietf.org References: <489B1171.2050101@cisco.com> In-Reply-To: <489B1171.2050101@cisco.com> Content-Type: multipart/mixed; boundary="------------080603010708010905000701" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.86,0.54 Cc: "Peterson, Jon" Subject: [Rucus] RUCUS Charter Text v2 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: , Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a multi-part message in MIME format. --------------080603010708010905000701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Based on the feedback I have updated the charter text. Please find the latest version attached to this mail Ciao Hannes --------------080603010708010905000701 Content-Type: text/plain; name="rucus-charter-version2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rucus-charter-version2.txt" Reducing Unwanted Communication Using SIP (RUCUS) Exploratory Group =================================================================== The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. Like other communication protocols, SIP is susceptible to unwanted communication attempts. RFC 5039 analyzes the problem of spam in SIP and examines various possible solutions that have been discussed for email and considers their applicability to SIP. RFC 5039 gives good, high-level recommendations regarding future work, namely to * Provide strong Identity * Provide White Lists * Solve the Introduction Problem * Don't Wait Until It's Too Late Among the many individual mechanisms that are discussed in RFC 5039 (including content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others) there is no clear guidance on whether one of the mechanisms listed - or something else entirely - is subject of additional standards work. Furthermore, since the publication of RFC 5039, many documents have been submitted to IETF that define frameworks, propose protocol headers, or describe additional guidelines on techniques listed in RFC 5039. These documents include: * draft-wing-sipping-spam-score * draft-jennings-sip-hashcash * draft-tschofenig-sipping-spit-policy * draft-tschofenig-sipping-captcha * draft-niccolini-sipping-feedback-spit (These are examples and not the complete list of published documents.) Despite the plethora of documents, there is debate in the community over whether there would be any value in pursuing any or all of these. The purpose of this exploratory group is to determine whether there are one or more mechanisms for mitigation of unsolicited communication, which would be reasonable subjects for standardization within the IETF. Reasonableness entails meeting the following criteria: * requires standardization to be effective, * there is some evidence that it would, in fact, have a demonstrable impact on the spit problem based on a plausibility threshold given certain assumptions * has a scope of applicability that is sufficiently broad to be useful To that end, this exploratory group is chartered with determining whether there are one or more mechanisms for preventing SPIT which would be reasonable subjects for standardization within the IETF, and if there are, to produce a charter for a working group to develop standards for such mechanisms. To achieve these goals, the working group will solicit inputs (in the form of individual Internet Drafts) which do the following: 1. describe the proposed mechanism in terms of information flow, information semantics, and how that information is used, at sufficient levels of detail to achieve the rest of the objectives below. Protocol machinery - such as headers, syntax, and so on - are irrelevant and distracting. However, sufficient detail must be given so that implementing the mechanism is a matter of engineering and design, and not 'research'. For example, a proposal which relies on consultation of an 'oracle', without describing at least one mechanism by which an oracle might answer a question, is not sufficient. As another example, a proposal which proposes that metrics be passed around without describing example metrics and how they are computed, is not sufficient. As an example, a proposal on 'spam scoring' might propose: "The originating domain of a call look at the caller's profile, and then compute the number of calls per day for that caller, and compare it to average. It then considers the ratio of these two as an indicator of a potential spammer. This ratio is then sent in the signaling from the calling to called domain. The called domain has a configured threshold, and if the ratio is above it, the call is discarded." This is the kind of level of detail that is needed. 2. describe the scope of applicability for the mechanism. Does it work within a domain only? Inter-domain? Require trust federations? Work in an environment where only some of the systems support it? Require changes in clients? In servers? Require centralized trust anchors? Work with human-generated or botnet-generated (recorded) spam? And so on. 3. clearly indicate why the author of the proposal believes the mechanism would, in fact, have a demonstrable impact on reducing spit. "Demonstrable" means that, an engineering argument could be made that, within the scope of applicability, there is a qualitative or quantitative analysis that shows that the volume of spit could be reduced. The proposal should pre-emptively capture arguments that could be made against the proposal. For example, a hashcash proposal needs to discuss the differences in computational capabilities between legitimate endpoints and how those differ from spammers. It is acceptable if the proposal doesn't work that well in the face of botnets, though this topic should be discussed. 4. clearly indicate why standardization is needed to make the mechanism work. Any mechanism which relies only on local computation within a host (for example, looking for malformed SIP requests) does not require standardization. At minimum the EG is going to discuss: * White lists * Spam scoring * Reputation systems * Turing tests There are proposals on the table around these mechanisms that at least some portion of the community believes would benefit from standardization. Authors of those proposals will turn them into the documentation described above. The group will additionally issue an open call for additional documentation. With proposals on the table, the EG will discuss the contents. The one and only purpose of that discussion is to make an assessment on whether there are one or more mechanisms which could plausibly have an impact on reducing unsolicited communications, and for which IETF standardization would be an appropriate action. Discussions on SIP details, headers vs. bodies, extensibility models, frameworks, terminology, and so on, would be out of scope for the EG discussion. Those discussions would be appropriate for a WG, should the EG decide to form one. Goals and Milestones: - Aug 2008 Formation of an exploratory working group - Sep 2008 Initial versions of high-level mechanism proposals meeting the criteria above, submitted as individual I-Ds - Oct/Nov 2008 Periodic (weekly or biweekly) telecons to discuss - Nov 2008 Continue discussions at the IETF meeting - Feb 2009 Agree on whether there should be an IETF WG, and if so, agree on a charter - Mar 2009 Close EG Mailing List: You can subscribe to the RUCUS mailing list (or to change your existing subscription) at: https://www.ietf.org/mailman/listinfo/rucus To post a message to all the list members, send email to rucus@ietf.org. --------------080603010708010905000701 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 --------------080603010708010905000701-- From rucus-bounces@ietf.org Sun Aug 10 13:16: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 9EFA53A6E01; Sun, 10 Aug 2008 13:16:48 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24D63A6DFC for ; Sun, 10 Aug 2008 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=1.860, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] 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 JxRmCIHqVkth for ; Sun, 10 Aug 2008 13:16:46 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2A43B3A6E01 for ; Sun, 10 Aug 2008 13:16:43 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2008 20:10:04 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp059) with SMTP; 10 Aug 2008 22:10:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/270oiYI/2J/8i9Y1Je5nn2PfUB4ELuc5RAJxSGQ PRfIOMkpaBhNIa Message-ID: <489F4B1E.1010102@gmx.net> Date: Sun, 10 Aug 2008 23:10:06 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Thomas Froment References: <4899C9A0.3000509@alcatel-lucent.fr> In-Reply-To: <4899C9A0.3000509@alcatel-lucent.fr> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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 Thomas, thanks for your feedback. Thomas Froment wrote: > Thanks for putting this together, I fully support this charter, > > some minor comments inlines... > >> The Session Initiation Protocol (SIP) is an application-layer control >> (signaling) protocol for creating, modifying, and terminating sessions >> with one or more participants. These sessions include Internet >> telephone calls, multimedia distribution, and multimedia >> conferences. Like other communication protocols, SIP is susceptible to >> unwanted communication attempts. RFC 5039 analyzes the problem of >> spam in SIP and examines various possible solutions that have been >> discussed for email and considers their applicability to SIP. >> >> RFC 5039 gives good, high-level recommendations regarding future work, >> namely to provide >> >> * Strong Identity >> * White Lists >> >> > Should say probably: > namely to: > * Provide strong Identity > * Provide White Lists > * Solve the Introduction Problem > * Don't Wait Until It's Too Late > > Done >> Among the many individual mechanisms that are discussed in RFC >> 5039 (including content filtering, black lists, white lists, >> consent-based communication, reputation systems, address obfuscation, >> limited use addresses, turing tests, computational puzzles, payments >> at risk, circles of trust, and many others) there is no clear guidance >> on whether one of the mechanisms listed - or something else entirely - >> is subject of additional standards work. >> >> Furthermore, since the publication of RFC 5039, many documents have >> been submitted to IETF which define frameworks, propose protocol >> headers, or document additional guidelines on techniques in RFC >> 5039. These documents include: >> >> * draft-wing-sipping-spam-score >> * draft-jennings-sip-hashcash >> * draft-tschofenig-sipping-spit-policy >> > should'nt we mention draft-froment-sipping-spit-requirements since it > comes with spit-policy? These are just examples -- not the complete list. >> * draft-tschofenig-sipping-captcha >> * draft-niccolini-sipping-feedback-spit >> >> Despite the plethora of documents, there is debate in the community >> over whether there would be any value in pursuing any or all of >> these. >> >> The purpose of this exploratory group is to determine whether there >> are one or more mechanisms for mitigation of unsoicited communication, >> > unsoicited --> unsolicited Done. >> which would be reasonable subjects for standardization within the IETF. >> Reasonableness entails meeting the following criteria: >> >> * requires standardization to be effective, >> * there is some evidence that it would, in fact, have a demonstrable >> impact on the spit problem based on a plausibility threshold >> given certain assumptions >> * has a scope of applicability that is sufficiently broad to be >> useful >> >> To that end, this exploratory group is chartered with determining >> whether there are one or more mechanisms for preventing SPIT which >> would be reasonable subjects for standardization within the IETF, and >> if there are, to produce a charter for a working group to develop >> standards for such mechanisms. >> >> To achieve these goals, the working group will solicit inputs (in the >> form of individual Internet Drafts) which do the following: >> >> 1. describe the proposed mechanism in terms of information flow, >> information semantics, and how that information is used, at >> sufficient levels of detail to achieve the rest of the objectives >> below. Protocol machinery - such as headers, syntax, and so on - are >> irrelevant and distracting. However, sufficient detail must be given >> so that implementing the mechanism is a matter of engineering and >> design, and not 'research'. For example, a proposal which relies on >> consultation of an 'oracle', without describing at least one >> mechanism by which an oracle might answer a question, is not >> sufficient. As another example, a proposal which proposes that >> metrics be passed around without describing example metrics and how >> they are computed, is not sufficient. >> >> As an example, a proposal on 'spam scoring' might propose: "The >> originating domain of a call look at the caller's profile, and then >> compute the number of calls per day for that caller, and compare it >> to average. It then considers the ratio of these two as an indicator >> of a potential spammer. This ratio is then sent in the signaling >> from the calling to called domain. The called domain has a >> configured threshold, and if the ratio is above it, the call is >> discarded." This is the kind of level of detail that is needed. >> >> 2. describe the scope of applicability for the mechanism. Does it >> work within a domain only? Inter-domain? Require trust federations? >> Work in an environment where only some of the systems support it? >> Require changes in clients? In servers? Require centralized trust >> anchors? Work with human-generated or botnet-generated (recorded) >> spam? And so on. >> >> 3. clearly indicate why the author of the proposal believes the >> mechanism would, in fact, have a demonstrable impact on reducing >> spit. "Demonstrable" means that, an engineering argument could be >> made that, within the scope of applicability, there is a qualitative >> or quantitative analysis that shows that the volume of spit could be >> reduced. The proposal should pre-emptively capture arguments that >> could be made against the proposal. For example, a hashcash proposal >> needs to discuss the differences in computational capabilities >> between legitimate endpoints and how those differ from spammers. It >> is acceptable if the proposal doesn't work that well in the face of >> botnets, though this topic should be discussed. >> >> 4. clearly indicate why standardization is needed to make the >> mechanism work. Any mechanism which relies only on local computation >> within a host (for example, looking for malformed SIP requests) does >> not require standardization. >> >> >> At minimum the EG is going to discuss: >> >> * spam scoring >> * reputation systems >> * Turing tests >> >> There are proposals on the table around these mechanisms that at least >> some portion of the community believes would benefit from >> standardization. Authors of those proposals will turn them into the >> documentation described above. The group will additionally issue an >> open call for additional documentation. >> >> With proposals on the table, the EG will discuss the contents. The one >> and only purpose of that discussion is to make an assessment on >> whether there are one or more mechanisms which could plausibly have an >> impact on reducing unsolicited communications, and for which IETF >> standardization would be an appropriate action. Discussions on SIP >> details, headers vs. bodies, extensibility models, frameworks, >> terminology, and so on, would be out of scope for the EG discussion. >> Those discussions would be appropriate for a WG, should the EG >> decide to form one. >> >> >> Goals and Milestones: >> >> Aug 2008 Formation of an exploratory working group >> Sep 2008 Initial versions of high-level mechanism proposals meeting >> the criteria above, submitted as individual I-Ds >> > The deadline of Sep 2008 seems to be very short to submit these > individual IDs, but well... We try to be ambigous. >> Oct/Nov 2008 Periodic (weekly or biweekly) telecons to discuss >> Nov 2008 Continue discussions at the IETF meeting >> Feb 2009 Agree on whether there should be an IETF WG, and if so, >> agree on a charter >> Mar 2009 Close EG > Ciao Hannes > Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi all, >> >> As you might have noticed, we got stuck a bit with the charter >> discussions on the list. Hence, a few of us, namely Mary Barnes, >> Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, Cullen Jennings >> and Jan Seedorf, used the IETF 72 meeting to chat about the RUCUS >> charter. >> >> Jonathan, Henning and I came up with a first text proposal based on the >> discussion we had during the meeting. Please find it in the attachment. >> >> Please let us know whether you find the current charter text acceptable. >> >> >> 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 Fri Aug 15 07:35: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 1568728C239; Fri, 15 Aug 2008 07:35:02 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735FC28C239 for ; Fri, 15 Aug 2008 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMMUjXb-VFkd for ; Fri, 15 Aug 2008 07:34:58 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 9D56528C236 for ; Fri, 15 Aug 2008 07:34:58 -0700 (PDT) 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 33467597; Fri, 15 Aug 2008 14:34:56 +0000 Message-Id: From: Dan York To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 15 Aug 2008 10:34:54 -0400 References: X-Mailer: Apple Mail (2.928.1) Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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, On Aug 5, 2008, at 5:02 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Jonathan, Henning and I came up with a first text proposal based on > the > discussion we had during the meeting. Please find it in the > attachment. > > Please let us know whether you find the current charter text > acceptable. Yes, subject to the minor edits that Thomas pointed out (and you've indicated you've modified), I think the charter looks fine. Given that this is already August 15th, I, too, wonder how realistic a September timeframe is for I-D's, but hey, at least we can try. Thanks to all of you who spent some time at IETF 72 working to move this forward, 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 Fri Aug 15 07:37: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 47DFD28C203; Fri, 15 Aug 2008 07:37:30 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9CD3A6A61 for ; Fri, 15 Aug 2008 07:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=-0.791, 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 f88tTkT6CRRt for ; Fri, 15 Aug 2008 07:37:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 76C953A6DCA for ; Fri, 15 Aug 2008 07:36:38 -0700 (PDT) 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 m7FEadUM012513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Aug 2008 16:36:39 +0200 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 m7FEadvO004094; Fri, 15 Aug 2008 16:36:39 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 16:36:39 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Aug 2008 16:36:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 15 Aug 2008 17:36:37 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS Charter Text v1 Thread-Index: Acj+5BwxTBRO/6LFSlaSSpT2bcyLjgAABscA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Dan York" X-OriginalArrivalTime: 15 Aug 2008 14:36:38.0764 (UTC) FILETIME=[538A72C0:01C8FEE4] Cc: rucus@ietf.org Subject: Re: [Rucus] RUCUS Charter Text v1 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 have incorporated the feedback received from Thomas. In my mail entitled as "RUCUS Charter Text v2" you can find the most recent version. I will chat with Jon & Cullen about the next steps. Ciao Hannes >-----Original Message----- >From: ext Dan York [mailto:dyork@voxeo.com] >Sent: 15 August, 2008 17:35 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: rucus@ietf.org >Subject: Re: [Rucus] RUCUS Charter Text v1 > >Hannes, > >On Aug 5, 2008, at 5:02 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Jonathan, Henning and I came up with a first text proposal based on >> the discussion we had during the meeting. Please find it in the >> attachment. >> >> Please let us know whether you find the current charter text >> acceptable. > >Yes, subject to the minor edits that Thomas pointed out (and >you've indicated you've modified), I think the charter looks >fine. Given that this is already August 15th, I, too, wonder >how realistic a September timeframe is for I-D's, but hey, at >least we can try. > >Thanks to all of you who spent some time at IETF 72 working to >move this forward, 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