From rucus-bounces@ietf.org Tue Jul 1 10:37:55 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613FC3A6784; Tue, 1 Jul 2008 10:37:55 -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 286813A6784 for ; Tue, 1 Jul 2008 10:37:54 -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 JSARvmN+AtB6 for ; Tue, 1 Jul 2008 10:37:52 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 055AC3A66B4 for ; Tue, 1 Jul 2008 10:37:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5F7EE2C000303; Tue, 1 Jul 2008 19:38:02 +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 1fdNDziqPmaX; Tue, 1 Jul 2008 19:38:02 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 343B02C000304; Tue, 1 Jul 2008 19:37:52 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Tue, 1 Jul 2008 19:37:50 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Charter proposal thread-index: AcjWMjAqReA/T3ETS++HNDo/7uPpzgFanPCA References: From: "Jan Seedorf" To: "Cullen Jennings" , Subject: Re: [Rucus] Charter proposal 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 Cullen, Thanks for taking the time to reply, I know you are busy so I appreciate it. > My recollection of the BOF (without going and checking the > notes so it may be wrong) is that there was reasonable > consensus on a specific set of work items in an EG that > involved the following: > > Taking some small set (~3) of techniques from existing drafts, > remove the implementation details and focus on the basic > approach, > turn them into a few pages and discuss the pros and cons and > applicability assumptions. From this form a plausible picture of > one way that might help mitigate unwanted communications. You recollection above is inline with mine. You are right that in the BoF in Philly it was agreed on what you summarize above and not more. It is just that after some discussions after the BoF we were thinking that RUCUSEG work should also address some of the issues presented in Henning's slides at the BoF. The reason is that we believe these issues to be key engineering tasks that need further exploration before a future WG could work on them (so perfect for an EG). I tried to summarize these ideas in order to see if people interested in the topic and willing to work on that share that view. My idea was not to question the agreement from Philly, but rather to raise the question on this mailing list if not in fact exploring the necessary communication between 3 techniques should additionally be part of RUCUSEG work and can be combined with the consensus from Philly. After all, consensus at the BoF does not exclude additions/variations if people on the mailing list agree on those. > This charter seems to be for a rather more specific set of > work items, namely mechanisms for exchange of spit-related > information between various parts of the SIP infrastructure. > It's quite possible that that's an important part of the > solution space, but I didn't hear any consensus in the room > that people wanted to focus solely on that. 1) You are right that there was no consensus in the room on that. This is exactly why I raised the question on this mailing list (through an email and later through a charter proposal), trying to find consensus for that on this list. Unfortunately there was not much feedback. 2) If the charter reads to be specific it needs to be rewritten because it was not intended in that way at all. In contrary, we believe the information exchange necessary between different entities to be a general engineering challenge which is a common necessity for different techniques. The idea is not to work solely on that but to combine this with the agreement from the room to work on 3 techniques. RUCUSEG could explore 3 techniques and the corresponding communication requirements for these techniques, this is our proposal in short. > I'd love to see an EG formed around SPAM, but I do think that > that group needs to be chartered more along the lines of the > consensus reached in Philadelphia. I'd encourage you to go > back and revise the draft charter so it's more consistent with that. We are not questioning the consensus from Philly, just trying to add some additional key points to explore and asking for feedback on this. There was not much support for this proposal on this list so far. So I can understand that you as AD must stick with the consensus from the BoF as long as there is no consensus on further confinements on this list. I hope we can discuss face-to-face also with other people interested in the topic in Dublin to see what the community thinks. If everybody agrees that the consensus from the BoF to work on three techniques only is the final scope for RUCUSEG we are certainly not against it and happy to start EG work on that. Kind regards, Jan > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Cullen Jennings > Sent: Tuesday, June 24, 2008 9:41 PM > To: rucus@ietf.org > Cc: Jan Seedorf > Subject: Re: [Rucus] Charter proposal > > My recollection of the BOF (without going and checking the > notes so it may be wrong) is that there was reasonable > consensus on a specific set of work items in an EG that > involved the following: > > Taking some small set (~3) of techniques from existing drafts, > remove the implementation details and focus on the basic > approach, > turn them into a few pages and discuss the pros and cons and > applicability assumptions. From this form a plausible picture of > one way that might help mitigate unwanted communications. > > This charter seems to be for a rather more specific set of > work items, namely mechanisms for exchange of spit-related > information between various parts of the SIP infrastructure. > It's quite possible that that's an important part of the > solution space, but I didn't hear any consensus in the room > that people wanted to focus solely on that. > > I'd love to see an EG formed around SPAM, but I do think that > that group needs to be chartered more along the lines of the > consensus reached in Philadelphia. I'd encourage you to go > back and revise the draft charter so it's more consistent with that. > > Cullen > > > On Jun 10, 2008, at 5:54 AM, Jan Seedorf wrote: > > > Dear all, > > > > A short while ago I sent an e-mail on this list, proposing > a direction > > and scope for RUCUS to work on as an EG. I received some > feedback on > > this list and some off-list. Since I did not receive any negative > > comments (convincing me that this is the wrong direction), > I tried to > > write these ideas up in a charter proposal for RUCUS. > > Below you can find a suggestion for a charter, describing > what I think > > should be the scope of RUCUSEG, the work to be done, and the > > corresponding achievable goals within the scope of an EG. > > > > Obviously, this is open for discussion. Any input/comment > on this is > > appreciated. > > > > Btw: We plan to organise a one-day workshop in Heidelberg > (right after > > IPTComm 2008) in order to discuss potential IETF work in > the area of > > Unsolicited Communications and to make progress on a charter for > > RUCUSEG agreed on by the community. I believe Saverio is > going to post > > details regarding this workshop on this list soon. > > > > Kind regards, > > Jan > > > > Charter Proposal for RUCUS: > > --------------------------------------- > > With massive deployment of SIP infrastructures it is > foreseeable that > > an increased amount of unsolicited communication will impose a > > potentially severe threat for real-time applications. > Efforts on how > > to reduce such a threat have received a lot of attention in > the IETF > > and have been recognized as an important item to be investigated by > > SIPPING. Preliminary investigations resulted already in the > > publication of RFC 5039. > > > > Unfortunately, so far, further discussions on the issue did > not find a > > big consensus on the approach to be followed. On the other > hand first > > products and solutions are now being developed and there is a big > > interest from different institutions to allow interoperability. > > This interest is reflected by many individual draft submissions, > > indicating an active community working in the area. > > > > For effectively mitigating unsolicited communications, an > exchange of > > information between different entities of a SIP infrastructure > > ("communication glue") is required. Which information is relevant, > > where in the network it is generated, and with which > entities it needs > > to be exchanged depends on the organization of the network and of > > communication between users (e.g., closed, semi-open, or > open groups). > > Examples of such "communication glue" are: configuring and > > communicating authorization policies, querying oracles (trust > > brokers), or conveying downstream metrics to use trust among peers. > > Such communication would allow for automated decisions with > respect to > > unsolicited communication, so that proper actions on a SIP > message can > > be taken (e.g., "forward to mailbox"). As a result, such > > "communication glue" would enable distributed communication > and allow > > mechanisms from different vendors to work together while mechanisms > > for mitigation can evolve and follow the threat evolutio n. > > > > It is not clear yet what precise properties are necessary to enable > > the exchange of information collected at different locations in a > > network (by different entities). A key challenge which has been > > identified for standardizing such communication is that attacks and > > mitigation mechanisms are likely to evolve. This implies > that a rather > > generic and flexible standard for information exchange is required, > > because a fixed standards tied to known potential attacks only may > > soon be outdated. > > > > Thus, in the spirit of an Exploratory Group, RUCUSEG will > explore the > > problem space and confine requirements for such flexible > exchange of > > information among different entities of a SIP > infrastructure. To lay > > out the path for a potential WG, RUCUSEG will derive the properties > > for mechanisms to communicate in a distributed setting, separating > > concrete mechanisms from communication protocols. As a main result, > > RUCUSEG will identify what communication protocol properties are > > necessary to achieve flexible exchange of information in a > way that it > > is independent of concrete mechanisms and allows for evolving > > mechanisms. > > > > In order to keep the work achievable within the context of an EG, > > RUCUSEG will select a few (e.g., 3) prototypical classes of > mechanisms > > as key ones and then work on confining how these could fit in an > > overall architecture and what kind of communication between > entities > > would be necessary for these classes of mechanisms in a distributed > > setting. The main goal of RUCUSEG is to summarize these > considerations > > in a document and to derive achievable goals for a > potential WG which > > can then start work in order to standardize communication > for reducing > > unsolicited communications. > > > > -- Goals/Milestones (6-12 months after work starts) > > -- WG charter for a follow-up WG (with consensus on the > mailing list) > > -- document on recommendations and achievable goals for a WG > > > > ============================================================ > > Jan Seedorf > > Research Scientist > > NEC Europe Ltd., NEC Laboratories Europe, Network Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel. +49 (0)6221 4342-221 > > Fax: +49 (0)6221 4342-155 > > e-mail: jan.seedorf@nw.neclab.eu > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 2 22:28:16 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4653A6AFF; Wed, 2 Jul 2008 22:28:16 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373E33A6AFF for ; Wed, 2 Jul 2008 22:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MISQMxTdW6Nq for ; Wed, 2 Jul 2008 22:28:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D09F63A67A6 for ; Wed, 2 Jul 2008 22:28:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="62437379" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2008 05:28:23 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m635SNa9024400; Wed, 2 Jul 2008 22:28:23 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.13.8/8.13.8) with SMTP id m635SItR007798; Thu, 3 Jul 2008 05:28:21 GMT From: Cullen Jennings To: Saverio Niccolini In-Reply-To: <547F018265F92642B577B986577D671C12137A@VENUS.office> Impp: xmpp:cullenfluffyjennings@jabber.org References: <547F018265F92642B577B986577D671C12137A@VENUS.office> Message-Id: Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 2 Jul 2008 22:28:08 -0700 X-Mailer: Apple Mail (2.924) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11070; t=1215062903; x=1215926903; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Rucus]=20Charter=20proposal |Sender:=20; bh=5wwTBcowXwEOnuuWOz6QXbZ/g+fHi8TFRKPI6T8JGVc=; b=vTvBHi1i5Y3ErNTQ59cOw+Vw8GZ7YOrgnkhWOJKayETm8lbVMWQPZ8l8wg xVdnoFSDDpzE8Oj+MkR7zk4rFnjKAjJb1nRpB2uXoky6Wf1fqanGMgkcLfgG H2ZFIN9duL; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rucus@ietf.org Subject: Re: [Rucus] Charter proposal 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 On Jun 25, 2008, at 9:21 AM, Saverio Niccolini wrote: > Dear Cullen, > > if you look carefully in the charter text (without always thinking > that we want to push only spam score) you will see that this charter > proposal is nothing more than: I was simply trying to help this charter move forward - I basically regret having sent any email on it now. > > -- a mix of Henning's presentation on architectural issues > merged with the 3 mechanisms proposal of Jonathan > > I do not see any hidden thing nor pushing of something that has > no consensus. I did not mean to imply it was. > > > We all agree that work currently established in SIPPING should have > precedence and policy framework is (one of) the best candidates > --> maybe this needs to be added as Mary pointed out > > I personally see no problems with the charter, if you still see > them can you please detail them more? > > If we do not know what is your exact objection, we will have hard > time to meet requirements for forming the EG... > > Looking forward to your answer, > 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 Juergen Quittek >> Sent: Wednesday, June 25, 2008 9:10 AM >> To: Cullen Jennings; rucus@ietf.org >> Cc: Jan Seedorf >> Subject: Re: [Rucus] Charter proposal >> >> Hi Cullen, >> >> Thanks for the feedback! >> >> On 24.06.08 21:40 "Cullen Jennings" wrote: >> >>> My recollection of the BOF (without going and checking the >> notes so it >>> may be wrong) is that there was reasonable consensus on a >> specific set >>> of work items in an EG that involved the following: >>> >>> Taking some small set (~3) of techniques from existing drafts, >> >> Maybe we have to be more clear about what a "technique" is. >> I think the charter proposal covers techniques from several existing >> drafts including >> a) configuring and communicating authorization policies >> b) querying oracles (trust brokers) >> c) conveying downstream metrics to use trust among peers >> By chance or intention these explicitly mentioned items are >> exactly three. >> >>> remove the implementation details and focus on the >> basic approach, >>> turn them into a few pages and discuss the pros and cons and >>> applicability assumptions. From this form a plausible >> picture of >>> one way that might help mitigate unwanted communications. >>> >>> This charter seems to be for a rather more specific set of >> work items, >>> namely mechanisms for exchange of spit-related information between >>> various parts of the SIP infrastructure. >> >> I do not see in what respect the charter proposal is specific. >> I would understand if you told us it would be too general, because >> it includes all work that has been contributed in drafts so far. >> >> An essential property of all three items a)-c) is that they require >> communication between entities of the SIP infrastructure, >> be it for exchanging very general authorization policies or for >> exchanging very specific information on a single call. >> I consider it quite natural, that the charter proposal reflects this. >> >> >>> It's quite possible that >>> that's an important part of the solution space, but I >> didn't hear any >>> consensus in the room that people wanted to focus solely on that. >> >> Again, I do not see any part of the solution space that is excluded. >> Can you give an example of a part of the solution space that is >> actually excluded. This would be extremely helpful. >> >> Thank you, >> >> Juergen >> >> >>> I'd love to see an EG formed around SPAM, but I do think that that >>> group needs to be chartered more along the lines of the consensus >>> reached in Philadelphia. I'd encourage you to go back and revise the >>> draft charter so it's more consistent with that. >>> >>> Cullen >>> >>> >>> On Jun 10, 2008, at 5:54 AM, Jan Seedorf wrote: >>> >>>> Dear all, >>>> >>>> A short while ago I sent an e-mail on this list, proposing a >>>> direction and scope for RUCUS to work on as an EG. I received some >>>> feedback on this list and some off-list. Since I did not >> receive any >>>> negative comments (convincing me that this is the wrong direction), >>>> I tried to write these ideas up in a charter proposal for RUCUS. >>>> Below you can find a suggestion for a charter, describing what I >>>> think should be the scope of RUCUSEG, the work to be done, and the >>>> corresponding achievable goals within the scope of an EG. >>>> >>>> Obviously, this is open for discussion. Any input/comment >> on this is >>>> appreciated. >>>> >>>> Btw: We plan to organise a one-day workshop in Heidelberg (right >>>> after IPTComm 2008) in order to discuss potential IETF work in the >>>> area of Unsolicited Communications and to make progress on >> a charter >>>> for RUCUSEG agreed on by the community. I believe Saverio is going >>>> to post details regarding this workshop on this list soon. >>>> >>>> Kind regards, >>>> Jan >>>> >>>> Charter Proposal for RUCUS: >>>> --------------------------------------- >>>> With massive deployment of SIP infrastructures it is foreseeable >>>> that an increased amount of unsolicited communication will impose a >>>> potentially severe threat for real-time applications. >> Efforts on how >>>> to reduce such a threat have received a lot of attention >> in the IETF >>>> and have been recognized as an important item to be investigated by >>>> SIPPING. Preliminary >>>> investigations resulted already in the publication of RFC 5039. >>>> >>>> Unfortunately, so far, further discussions on the issue >> did not find >>>> a big consensus on the approach to be followed. On the other hand >>>> first products and solutions are now being developed and there is a >>>> big interest from different institutions to allow interoperability. >>>> This interest is reflected by many individual draft submissions, >>>> indicating an active community working in the area. >>>> >>>> For effectively mitigating unsolicited communications, an exchange >>>> of information between different entities of a SIP infrastructure >>>> ("communication glue") is required. Which information is relevant, >>>> where in the network it is generated, and with which entities it >>>> needs to be exchanged depends on the organization of the >> network and >>>> of communication between users (e.g., closed, semi-open, or open >>>> groups). Examples of such "communication glue" are: configuring and >>>> communicating authorization policies, querying oracles (trust >>>> brokers), or conveying downstream metrics to use trust among peers. >>>> Such communication would allow for automated decisions with respect >>>> to unsolicited communication, so that proper actions on a SIP >>>> message can be taken (e.g., "forward to mailbox"). As a >> result, such >>>> "communication glue" would enable distributed communication and >>>> allow mechanisms from different vendors to work together while >>>> mechanisms for mitigation can evolve and follow the threat evolutio >>>> n. >>>> >>>> It is not clear yet what precise properties are necessary to enable >>>> the exchange of information collected at different locations in a >>>> network (by different entities). A key challenge which has been >>>> identified for standardizing such communication is that attacks and >>>> mitigation mechanisms are likely to evolve. This implies that a >>>> rather generic and flexible standard for information exchange is >>>> required, because a fixed standards tied to known potential attacks >>>> only may soon be outdated. >>>> >>>> Thus, in the spirit of an Exploratory Group, RUCUSEG will explore >>>> the problem space and confine requirements for such flexible >>>> exchange of information among different entities of a SIP >>>> infrastructure. To lay out the path for a potential WG, >>>> RUCUSEG will derive the properties for mechanisms to communicate in >>>> a distributed setting, separating concrete mechanisms from >>>> communication protocols. As a main result, RUCUSEG will identify >>>> what communication protocol properties are necessary to achieve >>>> flexible exchange of information in a way that it is independent of >>>> concrete mechanisms and allows for evolving >>>> mechanisms. >>>> >>>> In order to keep the work achievable within the context of an EG, >>>> RUCUSEG will select a few (e.g., 3) prototypical classes of >>>> mechanisms as key ones and then work on confining how these could >>>> fit in an overall architecture and what kind >>>> of communication between entities would be necessary for these >>>> classes of mechanisms in a distributed setting. The main >>>> goal of RUCUSEG is to summarize these considerations in a document >>>> and to derive achievable goals for a potential WG which can then >>>> start work in order to standardize communication for reducing >>>> unsolicited communications. >>>> >>>> -- Goals/Milestones (6-12 months after work starts) >>>> -- WG charter for a follow-up WG (with consensus on the >> mailing list) >>>> -- document on recommendations and achievable goals for a WG >>>> >>>> ============================================================ >>>> Jan Seedorf >>>> Research Scientist >>>> NEC Europe Ltd., NEC Laboratories Europe, Network Division >>>> Kurfuerstenanlage 36, D-69115 Heidelberg >>>> Tel. +49 (0)6221 4342-221 >>>> Fax: +49 (0)6221 4342-155 >>>> e-mail: jan.seedorf@nw.neclab.eu >>>> ============================================================ >>>> NEC Europe Limited Registered Office: NEC House, >>>> 1 Victoria Road, London W3 6BL Registered in England 2832014 >>>> _______________________________________________ >>>> Rucus mailing list >>>> Rucus@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rucus >>> >>> _______________________________________________ >>> Rucus mailing list >>> Rucus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rucus >> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Jul 28 08:10: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 F3B1E3A683C; Mon, 28 Jul 2008 08:10:29 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0EA3A65A6 for ; Mon, 28 Jul 2008 08:10:28 -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 S5UYm1itiDJw for ; Mon, 28 Jul 2008 08:10:26 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id B87813A6A43 for ; Mon, 28 Jul 2008 08:10:23 -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 33004568 for rucus@ietf.org; Mon, 28 Jul 2008 15:10:30 +0000 Message-Id: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> From: Dan York To: rucus BoF Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 28 Jul 2008 11:10:29 -0400 X-Mailer: Apple Mail (2.928.1) Subject: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 I noticed there is no RUCUS BOF scheduled in Dublin. I realize there are incredible time pressures on the RAI agenda and there are challenges getting slots for all groups... was a timeslot for RUCUS requested but then denied? Or was one not requested? 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 Mon Jul 28 08:14:42 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 0E71F28C164; Mon, 28 Jul 2008 08:14:42 -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 E190F28C0E0 for ; Mon, 28 Jul 2008 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 ENM1b5MHfoDF for ; Mon, 28 Jul 2008 08:14:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B3B0128C15F for ; Mon, 28 Jul 2008 08:14:39 -0700 (PDT) Received: (qmail invoked by alias); 28 Jul 2008 15:14:47 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp013) with SMTP; 28 Jul 2008 17:14:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/jte0gst7jMfv++iwoxoCZO5K0v0tpnTY4TBmMh8 wVRBrRM9rhEWiE Message-ID: <488DE266.30907@gmx.net> Date: Mon, 28 Jul 2008 18:14:46 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dan York References: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> In-Reply-To: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: rucus BoF Subject: Re: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 We had a BOF already. The BOF was successful in the sense that folks in the room wanted todo. Unfortunately, the discussions about the charter so far did not lead to anything. I am sue that's going to be fixed. Dan York wrote: > I noticed there is no RUCUS BOF scheduled in Dublin. I realize there > are incredible time pressures on the RAI agenda and there are > challenges getting slots for all groups... was a timeslot for RUCUS > requested but then denied? Or was one not requested? > > Dan > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Jul 28 11:25:26 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7E73A6A99; Mon, 28 Jul 2008 11:25:26 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F22D3A6A9F for ; Mon, 28 Jul 2008 11:25:25 -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 AUDQoeHZqdqX for ; Mon, 28 Jul 2008 11:25:23 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id BD8463A69EB for ; Mon, 28 Jul 2008 11:25:23 -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 33009984; Mon, 28 Jul 2008 18:25:31 +0000 Message-Id: <1C210FB6-EC56-4149-8AA3-B53B6102D8AB@voxeo.com> From: Dan York To: Hannes Tschofenig In-Reply-To: <488DE266.30907@gmx.net> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 28 Jul 2008 14:25:29 -0400 References: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> <488DE266.30907@gmx.net> X-Mailer: Apple Mail (2.928.1) Cc: rucus BoF Subject: Re: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 Jul 28, 2008, at 11:14 AM, Hannes Tschofenig wrote: > We had a BOF already. The BOF was successful in the sense that folks > in the room wanted todo. Okay, point taken. Back at IETF 71 we had a BOF to discuss forming an Exploratory Group. Now at IETF 72, it would be logical to have a meeting of either the BOF (again) or the Exploratory Group (EG). Neither is on the agenda. > Unfortunately, the discussions about the charter so far did not lead > to anything. I am sue that's going to be fixed. So to summarize... between IETF 71 and now there was no closure on the charter and therefore no meeting could be held at IETF 72. Thanks, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Jul 28 11:29: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 0522E28C285; Mon, 28 Jul 2008 11:29: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 82BFC28C285 for ; Mon, 28 Jul 2008 11:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 LqU7amMQBbq8 for ; Mon, 28 Jul 2008 11:29:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6BBC23A6AA0 for ; Mon, 28 Jul 2008 11:29:44 -0700 (PDT) Received: (qmail invoked by alias); 28 Jul 2008 18:29:48 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp055) with SMTP; 28 Jul 2008 20:29:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2JNZwqxv2JITkPRJq3vwPiggD3kOpN/lXLkDokl ZcASSDW3nYTKW+ Message-ID: <488E101C.1040608@gmx.net> Date: Mon, 28 Jul 2008 21:29:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dan York References: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> <488DE266.30907@gmx.net> <1C210FB6-EC56-4149-8AA3-B53B6102D8AB@voxeo.com> In-Reply-To: <1C210FB6-EC56-4149-8AA3-B53B6102D8AB@voxeo.com> X-Y-GMX-Trusted: 0 X-FuHaFi: -0.07000000000000001 Cc: rucus BoF Subject: Re: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 Dan, Dan York wrote: > Hannes, > > On Jul 28, 2008, at 11:14 AM, Hannes Tschofenig wrote: > >> We had a BOF already. The BOF was successful in the sense that folks >> in the room wanted todo. > > Okay, point taken. Back at IETF 71 we had a BOF to discuss forming an > Exploratory Group. Now at IETF 72, it would be logical to have a > meeting of either the BOF (again) or the Exploratory Group (EG). > Neither is on the agenda. It does not make sense to organize a BOF again since the other BOF was already successful. You cannot request a meeting slot if you don't have a group yet. Some of us are planning to meet during the meeting. Are you here in Dublin? > >> Unfortunately, the discussions about the charter so far did not lead >> to anything. I am sue that's going to be fixed. > > > So to summarize... between IETF 71 and now there was no closure on the > charter and therefore no meeting could be held at IETF 72. Yep. You have seen the discussions on the list. Very little feedback from various people. It seems that many folks are busy with something else. Those who have discussed something didn't advance things -- I would even argue that they went backwards. Ciao Hannes > > Thanks, > Dan > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Jul 28 12:23:28 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 9D7D63A6B18; Mon, 28 Jul 2008 12:23:28 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711CA3A6B17 for ; Mon, 28 Jul 2008 12:23:27 -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 c8JPx15AFC6V for ; Mon, 28 Jul 2008 12:23:26 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 194DC3A6B12 for ; Mon, 28 Jul 2008 12:23:25 -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 33011502; Mon, 28 Jul 2008 19:23:35 +0000 Message-Id: From: Dan York To: Hannes Tschofenig In-Reply-To: <488E101C.1040608@gmx.net> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 28 Jul 2008 15:23:33 -0400 References: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> <488DE266.30907@gmx.net> <1C210FB6-EC56-4149-8AA3-B53B6102D8AB@voxeo.com> <488E101C.1040608@gmx.net> X-Mailer: Apple Mail (2.928.1) Cc: rucus BoF Subject: Re: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 Jul 28, 2008, at 2:29 PM, Hannes Tschofenig wrote: >> Okay, point taken. Back at IETF 71 we had a BOF to discuss forming >> an Exploratory Group. Now at IETF 72, it would be logical to have >> a meeting of either the BOF (again) or the Exploratory Group (EG). >> Neither is on the agenda. > > It does not make sense to organize a BOF again since the other BOF > was already successful. Well... was the other BOF in fact successful? Given that no further work has taken place? The RTPSEC "BOF" met for what... 3 IETF meetings? It doesn't matter, really... the point is that there is no formal RUCUS meeting happening at IETF 72. > You cannot request a meeting slot if you don't have a group yet. > Some of us are planning to meet during the meeting. Are you here in > Dublin? I am unfortunately NOT in Dublin but am listening in to streaming audio and participating in Jabber chat rooms. (It was when I was planning my listening for the week that it dawned on me that there was no RUCUS session scheduled.) >> So to summarize... between IETF 71 and now there was no closure on >> the charter and therefore no meeting could be held at IETF 72. > Yep. You have seen the discussions on the list. Very little feedback > from various people. It seems that many folks are busy with > something else. Those who have discussed something didn't advance > things -- I would even argue that they went backwards. And I am as guilty of that as everyone else as the past few months have been insanely busy for me on a variety of work and personal fronts. It would seem that we need to regroup on-list (and in person for those of you there) and put the pieces together so that we can meet at IETF 73 and move the progress of this group along. Regards, Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Jul 29 01:35:45 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3FB28C123; Tue, 29 Jul 2008 01:35:45 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B803A6923 for ; Tue, 29 Jul 2008 01:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 UBR2ReaRF0ni for ; Tue, 29 Jul 2008 01:35:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 20F7E3A6935 for ; Tue, 29 Jul 2008 01:35:42 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2008 08:35:53 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp005) with SMTP; 29 Jul 2008 10:35:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+7fr8FHNy7ClTqJw6AdUo9BQHlq6OkB3qCGRxOiL TWSvDyHxLZHVJ0 Message-ID: <488ED665.5020003@gmx.net> Date: Tue, 29 Jul 2008 11:35:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dan York References: <192E2C93-EE68-4B9C-979D-2202EC764A97@voxeo.com> <488DE266.30907@gmx.net> <1C210FB6-EC56-4149-8AA3-B53B6102D8AB@voxeo.com> <488E101C.1040608@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: rucus BoF Subject: Re: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 Dan, Dan York wrote: > Hannes, > > On Jul 28, 2008, at 2:29 PM, Hannes Tschofenig wrote: >>> Okay, point taken. Back at IETF 71 we had a BOF to discuss forming >>> an Exploratory Group. Now at IETF 72, it would be logical to have >>> a meeting of either the BOF (again) or the Exploratory Group (EG). >>> Neither is on the agenda. >> >> It does not make sense to organize a BOF again since the other BOF >> was already successful. > > Well... was the other BOF in fact successful? Yes. The folks in the room thought that we should do some work in the discussed areas. > Given that no further work has taken place? The RTPSEC "BOF" met for > what... 3 IETF meetings? I have to check but I believe that there was only one BOF and the rest where some discussions attached to other sessions. > > It doesn't matter, really... the point is that there is no formal > RUCUS meeting happening at IETF 72. Yep. > >> You cannot request a meeting slot if you don't have a group yet. Some >> of us are planning to meet during the meeting. Are you here in Dublin? > > I am unfortunately NOT in Dublin but am listening in to streaming > audio and participating in Jabber chat rooms. (It was when I was > planning my listening for the week that it dawned on me that there was > no RUCUS session scheduled.) > >>> So to summarize... between IETF 71 and now there was no closure on >>> the charter and therefore no meeting could be held at IETF 72. >> Yep. You have seen the discussions on the list. Very little feedback >> from various people. It seems that many folks are busy with something >> else. Those who have discussed something didn't advance things -- I >> would even argue that they went backwards. > > > And I am as guilty of that as everyone else as the past few months > have been insanely busy for me on a variety of work and personal fronts. Correct. > > It would seem that we need to regroup on-list (and in person for those > of you there) and put the pieces together so that we can meet at IETF > 73 and move the progress of this group along. We are doing this while we chat. Ciao Hannes > > Regards, > Dan > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 30 05:23:06 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 EAB2F3A68EA; Wed, 30 Jul 2008 05:23:06 -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 6307D3A68C4 for ; Wed, 30 Jul 2008 05:23:05 -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 ZBIjLSf9amvf for ; Wed, 30 Jul 2008 05:23:04 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 819AB3A68A1 for ; Wed, 30 Jul 2008 05:23:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 018832C000352; Wed, 30 Jul 2008 14:23:18 +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 eRQcviOvYy2B; Wed, 30 Jul 2008 14:23:17 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id D703C2C000304; Wed, 30 Jul 2008 14:23:02 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 Jul 2008 12:23:02 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 30 Jul 2008 14:23:01 +0200 From: Juergen Quittek To: Dan York , Hannes Tschofenig Message-ID: Thread-Topic: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? Thread-Index: AcjyPwH49/Oz6mDVz0uLdqMFMdWRDA== In-Reply-To: Mime-version: 1.0 Cc: rucus BoF Subject: Re: [Rucus] Any particular reason there was no RUCUS BOF scheduled for Dublin? 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 Dan, > And I am as guilty of that as everyone else as the past few months > have been insanely busy for me on a variety of work and personal fronts. > > It would seem that we need to regroup on-list (and in person for those > of you there) and put the pieces together so that we can meet at IETF > 73 and move the progress of this group along. I thin this is the important point. Yes, there can be more than one BoF for establishing a WG or EG. However, as Hannes explained already, there is no need for another BoF. We just need all to work on a charter. There has been one proposal from Jan, see http://www.ietf.org/mail-archive/web/rucus/current/msg00261.html and http://www.ietf.org/mail-archive/web/rucus/current/msg00279.html This may be a starting point for a charter discussion. Alternatively, everybody is highly welcome to come up with their own charter proposal. Thanks, Juergen _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 30 05:58:54 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 9A24E3A6BE5; Wed, 30 Jul 2008 05:58:54 -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 B8D2B3A6BE5 for ; Wed, 30 Jul 2008 05:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 YGqI5Pa-lI0Y for ; Wed, 30 Jul 2008 05:58:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4CB873A6953 for ; Wed, 30 Jul 2008 05:58:51 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2008 12:58:58 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp010) with SMTP; 30 Jul 2008 14:58:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/9T5pVGTD9l5iH6W+fbvACJaBpGuid1U1UPkE22C n1B6JOFNBp2qti Message-ID: <48906593.9080305@gmx.net> Date: Wed, 30 Jul 2008 15:58:59 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: rucus BoF X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: [Rucus] Charter Proposal 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 RUCUS-EG: --------- 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 * Solve the Introduction Problem * Don't Wait Until It's Too Late Among the many individual building blocks 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 framework outlined how various mechanisms work together. It also does not indicate a ranking of specific solution approaches in order to determine which onces form an initial candiate set for subsequent standardization. This exploratory group is chartered for one year with the aim to create a venue where discussions on preventing unwanted communication in SIP can take place. The group will produce a framework document that sheds light on the interworking between various solution components. Architectural considerations are, for example, related to where information for decision making comes from, what information is required for the decision making process, where policy decision points / policy enforcement points are located, what privacy aspects need to be considered and how the underlying trust model looks like? A second document will then list a minimal set of initial solution approaches (such as 3 solution classes) that should be selected for later standardization, whereby the work will be done later in a new or an existing working group. This document will describe what the characteristics this solution set provides. This document is entitled as "Applicability of Selected SPIT Mechanisms". The group will consider prior work on SIP identity and related techniques and will consult with privacy experts to deal with the legal aspects of filtering communication attempts. Goals and Milestones: Aug 2008 Formation of an exploratory working group Aug 2008 First WG draft on the framework document Oct 2008 First WG draft on "Applicability of Selected SPIT Mechanisms" document Dec 2008 Submit framework document to the IESG for consideration as informational RFC Jan 2009 Submit "Applicability of Selected SPIT Mechanisms" document to the IESG for consideration as informational RFC Jul 2009 Close group _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 30 09:58:23 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 95EA53A6995; Wed, 30 Jul 2008 09:58:23 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A12A3A6995 for ; Wed, 30 Jul 2008 09:58:22 -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 EKQt2wPnWYBb for ; Wed, 30 Jul 2008 09:58:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4F9F83A68AF for ; Wed, 30 Jul 2008 09:58:21 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 56BF0207F6; Wed, 30 Jul 2008 18:58:35 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-23-48909dbbb1ac Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29879206D9; Wed, 30 Jul 2008 18:58:35 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 18:58:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 18:58:00 +0200 Message-ID: In-Reply-To: <48906593.9080305@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Charter Proposal Thread-Index: AcjyRBFf7hEmdE/8R+KTkNtjBpRzDQAG+1AA References: <48906593.9080305@gmx.net> From: "Michael Liljenstam" To: "Hannes Tschofenig" X-OriginalArrivalTime: 30 Jul 2008 16:58:05.0347 (UTC) FILETIME=[6F543F30:01C8F265] X-Brightmail-Tracker: AAAAAA== Cc: rucus BoF Subject: Re: [Rucus] Charter Proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes, It would be nice to see this moving forward. To that end, my recollections from the BOF comments include a desire to see (motivating) "scenarios" described, which I think is implicit in your text. Might it perhaps make sense to weave in something to also make this more explicit? Taking a stab at very slightly modifying one of your paragraphs: ... A second document will then list a minimal set of initial solution approaches (such as 3 solution classes) along with motivating scenarios that clarify what characteristics this solution set provides and what the expected limitations are. This set should be selected for later standardization, whereby the work will be done later in a new or an existing working group. This document is entitled "Applicability of Selected SPIT Mechanisms". ... Makes sense? Admittedly, this is only a minor nit. Just trying to preempt objections... Regards, Michael Liljenstam --- Michael Liljenstam Senior Research Engineer, Communications Security, Ericsson Research Phone: +46-8-404 4602, Email: firstname.lastname@ericsson.com > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: den 30 juli 2008 14:59 > To: rucus BoF > Subject: [Rucus] Charter Proposal > > RUCUS-EG: > --------- > > 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 > * Solve the Introduction Problem > * Don't Wait Until It's Too Late > > Among the many individual building blocks 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 framework outlined how various > mechanisms work together. It also does not indicate a ranking > of specific solution approaches in order to determine which > onces form an initial candiate set for subsequent standardization. > > This exploratory group is chartered for one year with the aim > to create a venue where discussions on preventing unwanted > communication in SIP can take place. The group will produce a > framework document that sheds light on the interworking > between various solution components. > Architectural considerations are, for example, related to > where information for decision making comes from, what > information is required for the decision making process, > where policy decision points / policy enforcement points are > located, what privacy aspects need to be considered and how > the underlying trust model looks like? > A second document will then list a minimal set of initial > solution approaches (such as 3 solution classes) that should > be selected for later standardization, whereby the work will > be done later in a new or an existing working group. This > document will describe what the characteristics this solution > set provides. This document is entitled as "Applicability of > Selected SPIT Mechanisms". > > The group will consider prior work on SIP identity and > related techniques and will consult with privacy experts to > deal with the legal aspects of filtering communication attempts. > > > Goals and Milestones: > > Aug 2008 Formation of an exploratory working group Aug 2008 > First WG draft on the framework document Oct 2008 First WG > draft on "Applicability of Selected SPIT Mechanisms" > document > Dec 2008 Submit framework document to the IESG for > consideration as informational RFC Jan 2009 Submit > "Applicability of Selected SPIT Mechanisms" document to the > IESG for consideration as informational RFC Jul 2009 Close group > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 30 15:06:57 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 0277B3A6B37; Wed, 30 Jul 2008 15:06:57 -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 86B323A6B2B for ; Wed, 30 Jul 2008 15:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uqRiGqn6f1z for ; Wed, 30 Jul 2008 15:06:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by core3.amsl.com (Postfix) with ESMTP id 534D23A6B31 for ; Wed, 30 Jul 2008 15:06:54 -0700 (PDT) Received: from [172.16.10.191] ([130.129.65.91]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KOJp63JGC-0000to; Thu, 31 Jul 2008 00:07:09 +0200 Message-Id: <91CE4BA9-0C0F-4625-A08E-DAAC237B2652@xconnect.net> From: David Schwartz To: Hannes Tschofenig In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 30 Jul 2008 23:07:06 +0100 References: <48906593.9080305@gmx.net> X-Mailer: Apple Mail (2.924) X-Provags-ID: V01U2FsdGVkX18YkeP1hNZsLXtcPjBhNtrbUmT065jVM+3/Hr2 Un32O9/SG2tVhThnWAOsxMcju7M0F5kS/xZi7oJTxz3TGRIiJ2 1fG/WHzKkzZD/MqHCKAXw== Cc: rucus BoF Subject: Re: [Rucus] Charter Proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes. The things I would add are: * limit EG to 6 months (not a year) - should be enough for specified goals * clear criteria for success so that upon success we roll right into WG * Perhaps schedule and interim meeting to really move this along D. _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 30 15:11: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 956963A68DD; Wed, 30 Jul 2008 15:11: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 7B6F63A67FB for ; Wed, 30 Jul 2008 15:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 BB4bb9GFkY9l for ; Wed, 30 Jul 2008 15:11:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 42DD43A68DD for ; Wed, 30 Jul 2008 15:11:19 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2008 22:11:31 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp062) with SMTP; 31 Jul 2008 00:11:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19wS8l8Tnxws0fYP71rtDm+Y6pibuqQBw8QTNg2OS dyP5hrv7DWHcSF Message-ID: <4890E70E.4030306@gmx.net> Date: Thu, 31 Jul 2008 01:11:26 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Schwartz References: <48906593.9080305@gmx.net> <91CE4BA9-0C0F-4625-A08E-DAAC237B2652@xconnect.net> In-Reply-To: <91CE4BA9-0C0F-4625-A08E-DAAC237B2652@xconnect.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: rucus BoF Subject: Re: [Rucus] Charter Proposal 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 David, Limiting the EG to 6 months puts more pressure on us to make decisions quickly. No need to delay things. I believe that's a good idea. I also like the two other suggestions. Thanks for the feedback Ciao Hannes David Schwartz wrote: > Hi Hannes. > > The things I would add are: > > * limit EG to 6 months (not a year) - should be enough for specified > goals > * clear criteria for success so that upon success we roll right into WG > * Perhaps schedule and interim meeting to really move this along > > D. _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jul 30 23:36:58 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 0B9263A6C21; Wed, 30 Jul 2008 23:36:58 -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 F128B3A6C21 for ; Wed, 30 Jul 2008 23:36:55 -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 g91pk9HaAI82 for ; Wed, 30 Jul 2008 23:36:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 7B2363A677C for ; Wed, 30 Jul 2008 23:36:54 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6V6b7ac015965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 08:37:07 +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 m6V6b7dC029747; Thu, 31 Jul 2008 08:37:07 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 08:37:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 31 Jul 2008 08:37:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Charter Proposal Thread-Index: AcjyRBFf7hEmdE/8R+KTkNtjBpRzDQAG+1AAAB3tlwA= References: <48906593.9080305@gmx.net> From: "Charzinski, Joachim (NSN - DE/Muenich)" To: "ext Michael Liljenstam" , "Hannes Tschofenig" X-OriginalArrivalTime: 31 Jul 2008 06:37:07.0786 (UTC) FILETIME=[DA815AA0:01C8F2D7] Cc: rucus BoF Subject: Re: [Rucus] Charter Proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hannes and Michael, shouldn't it read = ... working group. This document is entitled "Applicability of = Selected _Anti_-SPIT Mechanisms". ... ? Best regards Joachim. -----Original Message----- From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of e= xt Michael Liljenstam Sent: Wednesday, July 30, 2008 6:58 PM To: Hannes Tschofenig Cc: rucus BoF Subject: Re: [Rucus] Charter Proposal Hi Hannes, It would be nice to see this moving forward. To that end, my recollections from the BOF comments include a desire to see (motivating) "scenarios" described, which I think is implicit in your text. Might it perhaps make sense to weave in something to also make this more explicit? = Taking a stab at very slightly modifying one of your paragraphs: ... A second document will then list a minimal set of initial = solution approaches (such as 3 solution classes) along with = motivating scenarios that clarify what characteristics this = solution set provides and what the expected limitations are. = This set should be selected for later standardization, = whereby the work will be done later in a new or an existing = working group. This document is entitled "Applicability of = Selected SPIT Mechanisms". ... Makes sense? Admittedly, this is only a minor nit. Just trying to preempt objections... Regards, Michael Liljenstam --- Michael Liljenstam Senior Research Engineer, Communications Security, Ericsson Research Phone: +46-8-404 4602, Email: firstname.lastname@ericsson.com > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] = > On Behalf Of Hannes Tschofenig > Sent: den 30 juli 2008 14:59 > To: rucus BoF > Subject: [Rucus] Charter Proposal > = > RUCUS-EG: > --------- > = > 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 > * Solve the Introduction Problem > * Don't Wait Until It's Too Late > = > Among the many individual building blocks 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 framework outlined how various = > mechanisms work together. It also does not indicate a ranking = > of specific solution approaches in order to determine which = > onces form an initial candiate set for subsequent standardization. > = > This exploratory group is chartered for one year with the aim = > to create a venue where discussions on preventing unwanted = > communication in SIP can take place. The group will produce a = > framework document that sheds light on the interworking = > between various solution components. = > Architectural considerations are, for example, related to = > where information for decision making comes from, what = > information is required for the decision making process, = > where policy decision points / policy enforcement points are = > located, what privacy aspects need to be considered and how = > the underlying trust model looks like? > A second document will then list a minimal set of initial = > solution approaches (such as 3 solution classes) that should = > be selected for later standardization, whereby the work will = > be done later in a new or an existing working group. This = > document will describe what the characteristics this solution = > set provides. This document is entitled as "Applicability of = > Selected SPIT Mechanisms". > = > The group will consider prior work on SIP identity and = > related techniques and will consult with privacy experts to = > deal with the legal aspects of filtering communication attempts. > = > = > Goals and Milestones: > = > Aug 2008 Formation of an exploratory working group Aug 2008 = > First WG draft on the framework document Oct 2008 First WG = > draft on "Applicability of Selected SPIT Mechanisms" = > document > Dec 2008 Submit framework document to the IESG for = > consideration as informational RFC Jan 2009 Submit = > "Applicability of Selected SPIT Mechanisms" document to the = > IESG for consideration as informational RFC Jul 2009 Close group > = > = > = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > = _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus ---------------------------------------------------------- Joachim Charzinski Principal Innovator Nokia Siemens Networks Research, Technology and Platforms / Innovations = St.-Martin-Str. 53 Post box: D-80240 Muenchen D-81541 Muenchen Germany Tel: +49 89 636 79902 Joachim.Charzinski@nsn.com = http://www.nokiasiemensnetworks.com/global/ Think before you print Nokia Siemens Networks GmbH & Co. KG Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 WEEE-Reg.-Nr.: DE 52984304 Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens Net= works Management GmbH Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivin= en Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Jul 31 00:23:05 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 6D7353A6C55; Thu, 31 Jul 2008 00:23:05 -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 8AB703A6C54 for ; Thu, 31 Jul 2008 00:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 43dJraObLCae for ; Thu, 31 Jul 2008 00:23:03 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3079B3A6C4E for ; Thu, 31 Jul 2008 00:23:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 70B832C000359; Thu, 31 Jul 2008 09:23:17 +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 tImub3g750wT; Thu, 31 Jul 2008 09:23:17 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 3E2DF2C00035A; Thu, 31 Jul 2008 09:22:57 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Jul 2008 07:22:57 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Thu, 31 Jul 2008 09:22:54 +0200 From: Juergen Quittek To: "Charzinski, Joachim (NSN - DE/Muenich)" , ext Michael Liljenstam , Hannes Tschofenig Message-ID: Thread-Topic: [Rucus] Charter Proposal Thread-Index: AcjyRBFf7hEmdE/8R+KTkNtjBpRzDQAG+1AAAB3tlwAAAaKZVA== In-Reply-To: Mime-version: 1.0 Cc: rucus BoF Subject: Re: [Rucus] Charter Proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Joachim, I don't think the charter needs to fix a title. It should be sufficient to agree on the content. And yes, of course the document should be about the applicability of selected mechanisms for mitigating SPIT. Thanks, Juergen On 31.07.08 08:37 "Charzinski, Joachim (NSN - DE/Muenich)" wrote: > Hi Hannes and Michael, > = > shouldn't it read > ... > working group. This document is entitled "Applicability of > Selected _Anti_-SPIT Mechanisms". > ... > ? > = > Best regards > = > Joachim. > = > = > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of= ext > Michael Liljenstam > Sent: Wednesday, July 30, 2008 6:58 PM > To: Hannes Tschofenig > Cc: rucus BoF > Subject: Re: [Rucus] Charter Proposal > = > Hi Hannes, > = > It would be nice to see this moving forward. To that end, my > recollections from the BOF comments include a desire to see (motivating) > "scenarios" described, which I think is implicit in your text. Might it > perhaps make sense to weave in something to also make this more > explicit? = > Taking a stab at very slightly modifying one of your paragraphs: > = > ... > A second document will then list a minimal set of initial > solution approaches (such as 3 solution classes) along with > motivating scenarios that clarify what characteristics this > solution set provides and what the expected limitations are. > This set should be selected for later standardization, > whereby the work will be done later in a new or an existing > working group. This document is entitled "Applicability of > Selected SPIT Mechanisms". > ... > = > Makes sense? > Admittedly, this is only a minor nit. Just trying to preempt > objections... > = > Regards, > Michael Liljenstam > = > --- > Michael Liljenstam > Senior Research Engineer, Communications Security, Ericsson Research > Phone: +46-8-404 4602, Email: firstname.lastname@ericsson.com > = > = >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Hannes Tschofenig >> Sent: den 30 juli 2008 14:59 >> To: rucus BoF >> Subject: [Rucus] Charter Proposal >> = >> RUCUS-EG: >> --------- >> = >> 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 >> * Solve the Introduction Problem >> * Don't Wait Until It's Too Late >> = >> Among the many individual building blocks 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 framework outlined how various >> mechanisms work together. It also does not indicate a ranking >> of specific solution approaches in order to determine which >> onces form an initial candiate set for subsequent standardization. >> = >> This exploratory group is chartered for one year with the aim >> to create a venue where discussions on preventing unwanted >> communication in SIP can take place. The group will produce a >> framework document that sheds light on the interworking >> between various solution components. >> Architectural considerations are, for example, related to >> where information for decision making comes from, what >> information is required for the decision making process, >> where policy decision points / policy enforcement points are >> located, what privacy aspects need to be considered and how >> the underlying trust model looks like? >> A second document will then list a minimal set of initial >> solution approaches (such as 3 solution classes) that should >> be selected for later standardization, whereby the work will >> be done later in a new or an existing working group. This >> document will describe what the characteristics this solution >> set provides. This document is entitled as "Applicability of >> Selected SPIT Mechanisms". >> = >> The group will consider prior work on SIP identity and >> related techniques and will consult with privacy experts to >> deal with the legal aspects of filtering communication attempts. >> = >> = >> Goals and Milestones: >> = >> Aug 2008 Formation of an exploratory working group Aug 2008 >> First WG draft on the framework document Oct 2008 First WG >> draft on "Applicability of Selected SPIT Mechanisms" >> document >> Dec 2008 Submit framework document to the IESG for >> consideration as informational RFC Jan 2009 Submit >> "Applicability of Selected SPIT Mechanisms" document to the >> IESG for consideration as informational RFC Jul 2009 Close group >> = >> = >> = >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> = > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > = > ---------------------------------------------------------- > Joachim Charzinski > Principal Innovator > = > Nokia Siemens Networks > Research, Technology and Platforms / Innovations > = > St.-Martin-Str. 53 > Post box: D-80240 Muenchen > D-81541 Muenchen > Germany > Tel: +49 89 636 79902 > = > Joachim.Charzinski@nsn.com > http://www.nokiasiemensnetworks.com/global/ > = > Think before you print > = > Nokia Siemens Networks GmbH & Co. KG > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRA 88537 > WEEE-Reg.-Nr.: DE 52984304 > = > Pers=F6nlich haftende Gesellschafterin / General Partner: Nokia Siemens N= etworks > Management GmbH > Gesch=E4ftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke > Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kiv= inen > Sitz der Gesellschaft: M=FCnchen / Registered office: Munich > Registergericht: M=FCnchen / Commercial registry: Munich, HRB 163416 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus