Subject: Re: [cnit] [stir] Reputation vs Display name (was Textual caller ID)

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sun, 1 Sep 2013 10:10:51 +0000

Brian

Your DB? With our data....

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Labs - Network Technology
+1-609-903-3360
[email-masked]

On Aug 31, 2013, at 3:36 PM, "Dave Crocker" <[email-masked]> wrote:

> On 8/30/2013 10:40 AM, Brian Rosen wrote:
>> Okay.  We support dozens of customers who had serious fraud abuse
>> until they started using our database to evaluate callers to their
>> call center.
> 
> OK.  Good starting point.  Call centers represent specialized user organizations, with operators have some distinct skills and training, but a useful reference.  If the intended scope of the current work is... everyone in the world... then there are some issues in generalizing the experience from a few dozen skilled user organizations to billions of individual users.  But, again, a good starting point.
> 
> 
>> Typically, they query with 3-6 fields.  They get a
>> score back.  They decide how to handle the caller based on the score.
> 
> I assume that the call center operators have established procedures, rather than creating an action based personal whim of the moment. Again, this would distinguish them from typical, mass-market end users.
> 
> 
>> The part of this that I can't cite a specific example for is what
>> some clever UI developer will come up with to use the data.
> 
> Unfortunately that part of the equation matters.  Not necessarily the fine-grained detail, but the basic expectations of how information will get used and by whom and whether it is pre-determined or decided in real-time.
> 
> That's why I am trying to distinguish between an architectural component that implements policies -- the same as the filtering engine in email anti-abuse systems today -- versus assumptions that end-users will be making real-time decisions, largely based on raw information.
> 
> In fact, the essential difference is between having a software policy engine with built-in rulesets, versus a 'wet' real-time policy formulation engine.
> 
> 
> >  What I
>> know is, it's useful, and we'll figure out a way.
> 
> Then you know more than I do, in spite of my background in usability design and the considerable industry experience in this space, which frankly encourages caution in this realm.
> 
> 
>> It might have
>> binned responses.  It might change the response if this is the first
>> call from the identity.  It might supply a thumbs up/down selection
>> that is used for other callers.  It might supply a Travelocity style
>> rating.
> 
> So it turns out that what you've described is considerably more than clever UI design.
> 
> You've describe the effects of a policy engine that does its own analysis and handling decisions.  And indeed, that's exactly the distinction I'm suggesting for this work.  With luck, that means we're disagreeing on some terminology, rather than some architecture.
> 
> However, this is not a small point.  It is a key architectural component and designing for that function, rather than designing for end-users, per se, is a fundamental difference.
> 
> 
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> _______________________________________________
> cnit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cnit

---

From: Brian Rosen <[email-masked]>
Date: Tue, 3 Sep 2013 09:18:11 -0400

No, AFAIK, it's not your data.  There is no NPAC data in there, for example.

Brian