Re: [Rucus] RUCUS Charter Text v1

Thanks for putting this together, I fully support this charter,

some minor comments inlines...

> The Session Initiation Protocol (SIP) is an application-layer control
> (signaling) protocol for creating, modifying, and terminating sessions
> with one or more participants.  These sessions include Internet
> telephone calls, multimedia distribution, and multimedia
> conferences. Like other communication protocols, SIP is susceptible to
> unwanted communication attempts.  RFC 5039 analyzes the problem of
> spam in SIP and examines various possible solutions that have been
> discussed for email and considers their applicability to SIP.
>
> RFC 5039 gives good, high-level recommendations regarding future work,
> namely to provide
>
> * Strong Identity
> * White Lists
>
>   
Should say probably:

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

> Among the many individual mechanisms that are discussed in RFC
> 5039 (including content filtering, black lists, white lists,
> consent-based communication, reputation systems, address obfuscation,
> limited use addresses, turing tests, computational puzzles, payments
> at risk, circles of trust, and many others) there is no clear guidance
> on whether one of the mechanisms listed - or something else entirely -
> is subject of additional standards work. 
>
> Furthermore, since the publication of RFC 5039, many documents have
> been submitted to IETF which define frameworks, propose protocol
> headers, or document additional guidelines on techniques in RFC
> 5039. These documents include:
>
> * draft-wing-sipping-spam-score 
> * draft-jennings-sip-hashcash 
> * draft-tschofenig-sipping-spit-policy 
>   
should'nt we mention draft-froment-sipping-spit-requirements since it 
comes with spit-policy?
> * draft-tschofenig-sipping-captcha 
> * draft-niccolini-sipping-feedback-spit
>
> Despite the plethora of documents, there is debate in the community
> over whether there would be any value in pursuing any or all of
> these. 
>
> The purpose of this exploratory group is to determine whether there
> are one or more mechanisms for mitigation of unsoicited communication, 
>   
unsoicited --> unsolicited

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

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