Re: [Rucus] RUCUS Charter Text v1

Hi Thomas,

thanks for your feedback.

Thomas Froment wrote:
> Thanks for putting this together, I fully support this charter,
>
> some minor comments inlines...
>   
>> The Session Initiation Protocol (SIP) is an application-layer control
>> (signaling) protocol for creating, modifying, and terminating sessions
>> with one or more participants.  These sessions include Internet
>> telephone calls, multimedia distribution, and multimedia
>> conferences. Like other communication protocols, SIP is susceptible to
>> unwanted communication attempts.  RFC 5039 analyzes the problem of
>> spam in SIP and examines various possible solutions that have been
>> discussed for email and considers their applicability to SIP.
>>
>> RFC 5039 gives good, high-level recommendations regarding future work,
>> namely to provide
>>
>> * Strong Identity
>> * White Lists
>>
>>   
> Should say probably:
> namely to:
> * Provide strong Identity
> * Provide White Lists
> * Solve the Introduction Problem
> * Don't Wait Until It's Too Late
>   
>
Done

>> Among the many individual mechanisms that are discussed in RFC
>> 5039 (including content filtering, black lists, white lists,
>> consent-based communication, reputation systems, address obfuscation,
>> limited use addresses, turing tests, computational puzzles, payments
>> at risk, circles of trust, and many others) there is no clear guidance
>> on whether one of the mechanisms listed - or something else entirely -
>> is subject of additional standards work. 
>>
>> Furthermore, since the publication of RFC 5039, many documents have
>> been submitted to IETF which define frameworks, propose protocol
>> headers, or document additional guidelines on techniques in RFC
>> 5039. These documents include:
>>
>> * draft-wing-sipping-spam-score 
>> * draft-jennings-sip-hashcash 
>> * draft-tschofenig-sipping-spit-policy 
>>   
> should'nt we mention draft-froment-sipping-spit-requirements since it 
> comes with spit-policy? 
These are just examples -- not the complete list.

>> * draft-tschofenig-sipping-captcha 
>> * draft-niccolini-sipping-feedback-spit
>>
>> Despite the plethora of documents, there is debate in the community
>> over whether there would be any value in pursuing any or all of
>> these. 
>>
>> The purpose of this exploratory group is to determine whether there
>> are one or more mechanisms for mitigation of unsoicited communication, 
>>   
> unsoicited --> unsolicited
Done.

>> which would be reasonable subjects for standardization within the IETF. 
>> Reasonableness entails meeting the following criteria:
>>
>>   * requires standardization to be effective,
>>   * there is some evidence that it would, in fact, have a demonstrable
>>     impact on the spit problem based on a plausibility threshold 
>>     given certain assumptions
>>   * has a scope of applicability that is sufficiently broad to be
>>     useful
>>
>> To that end, this exploratory group is chartered with determining
>> whether there are one or more mechanisms for preventing SPIT which
>> would be reasonable subjects for standardization within the IETF, and
>> if there are, to produce a charter for a working group to develop
>> standards for such mechanisms.
>>
>> To achieve these goals, the working group will solicit inputs (in the
>> form of individual Internet Drafts) which do the following:
>>
>>   1. describe the proposed mechanism in terms of information flow,
>>   information semantics, and how that information is used, at
>>   sufficient levels of detail to achieve the rest of the objectives
>>   below. Protocol machinery - such as headers, syntax, and so on - are
>>   irrelevant and distracting. However, sufficient detail must be given
>>   so that implementing the mechanism is a matter of engineering and
>>   design, and not 'research'. For example, a proposal which relies on
>>   consultation of an 'oracle', without describing at least one
>>   mechanism by which an oracle might answer a question, is not
>>   sufficient. As another example, a proposal which proposes that
>>   metrics be passed around without describing example metrics and how
>>   they are computed, is not sufficient.
>>
>>   As an example, a proposal on 'spam scoring' might propose: "The
>>   originating domain of a call look at the caller's profile, and then
>>   compute the number of calls per day for that caller, and compare it
>>   to average. It then considers the ratio of these two as an indicator
>>   of a potential spammer. This ratio is then sent in the signaling
>>   from the calling to called domain. The called domain has a
>>   configured threshold, and if the ratio is above it, the call is
>>   discarded." This is the kind of level of detail that is needed. 
>>
>>   2. describe the scope of applicability for the mechanism. Does it
>>   work within a domain only? Inter-domain? Require trust federations?
>>   Work in an environment where only some of the systems support it?
>>   Require changes in clients? In servers? Require centralized trust
>>   anchors? Work with human-generated or botnet-generated (recorded) 
>>   spam? And so on.
>>
>>   3. clearly indicate why the author of the proposal believes the
>>   mechanism would, in fact, have a demonstrable impact on reducing
>>   spit. "Demonstrable" means that, an engineering argument could be
>>   made that, within the scope of applicability, there is a qualitative
>>   or quantitative analysis that shows that the volume of spit could be
>>   reduced. The proposal should pre-emptively capture arguments that
>>   could be made against the proposal. For example, a hashcash proposal
>>   needs to discuss the differences in computational capabilities
>>   between legitimate endpoints and how those differ from spammers. It
>>   is acceptable if the proposal doesn't work that well in the face of 
>>   botnets, though this topic should be discussed.
>>
>>   4. clearly indicate why standardization is needed to make the
>>   mechanism work. Any mechanism which relies only on local computation
>>   within a host (for example, looking for malformed SIP requests) does
>>   not require standardization.
>>
>>
>> At minimum the EG is going to discuss:
>>
>>    * spam scoring
>>    * reputation systems
>>    * Turing tests
>>
>> There are proposals on the table around these mechanisms that at least
>> some portion of the community believes would benefit from
>> standardization. Authors of those proposals will turn them into the
>> documentation described above. The group will additionally issue an
>> open call for additional documentation.
>>
>> With proposals on the table, the EG will discuss the contents. The one
>> and only purpose of that discussion is to make an assessment on
>> whether there are one or more mechanisms which could plausibly have an
>> impact on reducing unsolicited communications, and for which IETF 
>> standardization would be an appropriate action. Discussions on SIP 
>> details, headers vs. bodies, extensibility models, frameworks, 
>> terminology, and so on, would be out of scope for the EG discussion. 
>> Those discussions would be appropriate for a WG, should the EG 
>> decide to form one.
>>
>>
>> Goals and Milestones:
>>
>> Aug 2008  Formation of an exploratory working group
>> Sep 2008  Initial versions of high-level mechanism proposals meeting
>> the criteria above, submitted as individual I-Ds
>>   
> The deadline of Sep 2008 seems to be very short to submit these 
> individual IDs, but well...
We try to be ambigous.

>> Oct/Nov 2008  Periodic (weekly or biweekly) telecons to discuss
>> Nov 2008  Continue discussions at the IETF meeting
>> Feb 2009  Agree on whether there should be an IETF WG, and if so,
>> agree on a charter
>> Mar 2009  Close EG
>
Ciao
Hannes

> Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>> Hi all, 
>>
>> As you might have noticed, we got stuck a bit with the charter
>> discussions on the list. Hence, a few of us, namely Mary Barnes,
>> Jonathan Rosenberg, Jon Peterson, Henning Schulzrinne, Cullen Jennings
>> and Jan Seedorf, used the IETF 72 meeting to chat about the RUCUS
>> charter. 
>>
>> Jonathan, Henning and I came up with a first text proposal based on the
>> discussion we had during the meeting. Please find it in the attachment. 
>>
>> Please let us know whether you find the current charter text acceptable.
>>
>>
>> Ciao
>> Hannes
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Rucus mailing list
>> Rucus@ietf.org
>> https://www.ietf.org/mailman/listinfo/rucus
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rucus mailing list
> Rucus@ietf.org
> https://www.ietf.org/mailman/listinfo/rucus
>   

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