Subject: [Rucus] RUCUS Charter Text v1

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 5 Aug 2008 12:02:41 +0300

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
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 5 Aug 2008 17:36:51 +0200

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:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Tuesday, August 05, 2008 11:03 AM
> To: [email-masked]
> 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. 
>

---

From: Thomas Froment <[email-masked]>
Date: Wed, 06 Aug 2008 17:56:16 +0200

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

---

From: "Michael Liljenstam" <[email-masked]>
Date: Wed, 6 Aug 2008 20:58:20 +0200

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: [email-masked]

> Sent: den 5 augusti 2008 11:03
> To: [email-masked]

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 7 Aug 2008 15:38:10 +0200

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

> On Behalf Of Michael Liljenstam
> Sent: Wednesday, August 06, 2008 8:58 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> Subject: Re: [Rucus] RUCUS Charter Text v1
> 
> Hi,
> 
> 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
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Tschofenig, Hannes (NSN - FI/Espoo)
> > and Jan Seedorf, used the IETF
> > 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.
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 07 Aug 2008 16:51:09 +0300

Thanks for your feedback, Michael.

We just forgot about it while writing the text. I added it.

Michael Liljenstam wrote:
> 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
The introduction problem for certain communication patters are indeed 
challenging.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 07 Aug 2008 16:57:38 +0300

A quick comment.

> communications but "whitelists" as such are not really subject

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.

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

Ciao
Hannes

>>> Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, 
>>>       
>> Cullen Jennings 
>>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 7 Aug 2008 10:27:20 -0400

Pl. see inline .. 

>On Behalf Of Hannes Tschofenig
>Sent: Thursday, August 07, 2008 9:58 AM
>To: Saverio Niccolini
>Cc: [email-masked]
>> communications but "whitelists" as such are not really subject of 
>> standardization.
>>
>>   
>
>http://www.ietf.org/rfc/rfc5025.txt (Presence Authorization 
>Rules; using Common Policy)
>
>The later do not require a standardized mechanism since they 
>are executed locally and will rarely change.
>
>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?
>>
>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
>> London W3 6BL Registered in England 2832014
>>  
>>   
>>
>>   
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Michael Liljenstam
>>> 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
>based on

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Aug 2008 11:14:57 -0400

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.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 10 Aug 2008 23:13:09 +0300

> created on to the central datastore.
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?

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 10 Aug 2008 23:13:25 +0300

Based on the feedback I have updated the charter text. Please find the 
latest version attached to this mail

Ciao
Hannes

Reducing Unwanted Communication Using SIP (RUCUS) Exploratory Group
===================================================================

namely to

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:

(These are examples and not the complete list of published 
documents.)

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:

   * White lists
   * Spam scoring
   * Reputation systems
   * Turing tests

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 [email-masked]. 
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 10 Aug 2008 23:10:06 +0300

Hi Thomas,

thanks for your feedback.

> * Don't Wait Until It's Too Late
Done

> should'nt we mention draft-froment-sipping-spit-requirements since it 
These are just examples -- not the complete list.

> unsoicited --> unsolicited
Done.

> individual IDs, but well...
We try to be ambigous.

Ciao
Hannes

---

From: Dan York <[email-masked]>
Date: Fri, 15 Aug 2008 10:34:54 -0400

Hannes,

On Aug 5, 2008, at 5:02 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> the

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     [email-masked]
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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 15 Aug 2008 17:36:37 +0300

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

>From: ext Dan York [mailto:[email-masked]] 
>Sent: 15 August, 2008 17:35
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]
>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
>
>--