Re: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00

["Saverio Niccolini" <[e-mail]>]

Hannes,

> You are right that this mechanism does not make a lot of 
> sense if you consider an architecture that uses authorization 
> policies and whitelists in particular.

Wrong...
In the case a spammer will get through the "white list and authorization
policies" framework then you have an additional weapon to just report abuse
which is automatic and not manual (call my friend and tell him).

Telling it to your proxy could be a way of updating your authorization 
policies (maybe even update your personal black list at the domain)
and to share info on the caller with the domain (to get to a domain-wide
reputation system, with all pros and cons)

> It makes some sense when you consider these statistical 
> learning techniques that require "good" and "bad" examples to learn.

Again wrong...
The feedback can be also linked to "binary" decisions like:
if I send a bad feedback for a caller "deny him from calling me
for today" or "next time challenge him with a CAPTCHA"

> This is obviously a -00 draft and I believe we should end up 
> with this work is more something along the lines of Peter's work
> 
> http://www.xmpp.org/extensions/inbox/error-abuse.html
> where there is communication between proxies rather than 
> between the end host and the proxy. 

I agree there must be many updates to the draft (proxy to proxy
communication is one of them) and I will take into account
the valuable point of Jonathan when submitting the next version.

Saverio

> 
> Ciao
> Hannes
> 
> 
> 
> Jonathan Rosenberg wrote:
> > Thanks for writing this, its a good topic to discuss.
> >
> > One thing that wasn't clear; what is the benefit of signaling 
> > something as spam to my proxy, as opposed to just putting 
> the sender 
> > on a black list. We have mechanisms defined already for that, for 
> > example. I suspect its around sharing of the spam 
> classification with 
> > other users in the domain. Its worth discussing this.
> >
> > Seems easier if you just send the entire sip message as 
> content rather 
> > than picking apart pieces of it.
> >
> > The mechanism is clearly intended to be between a UA and a proxy in 
> > its own domain; however I didn't find that stated till much 
> deeper in 
> > the document. This should be clear up front.
> >
> > In terms of specific protocols, I think SUB/NOT is a very 
> poor choice. 
> > The proxy will require a subscription to EVERY UA, and the 
> events will 
> > be infrequent. This means a lot of overhead for little 
> data. I think 
> > you are much better off with an asynchronous push, either 
> PUBLISH or 
> > even non-sip. Maybe a REST interface or something.
> >
> > Thanks,
> > Jonathan R.
> >
> >
> >   
> 
> _______________________________________________
> Rucus mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/rucus
> 


============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     [phone]
Fax:     [phone]
e-mail:  [e-mail] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 283201
_______________________________________________
Rucus mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/rucus