Re: [sipcore] Alissa Cooper's No Objection on draft-ietf-sipcore-rejected-08: (with COMMENT)

[Eric Burger <[e-mail]>]

inline

> On Jun 11, 2019, at 12:17 PM, Alissa Cooper via Datatracker <[e-mail]> wrote:
> 
> Please respond to the Gen-ART review.
> 
> = Section 3 =
> 
> I'm wondering about the case where I have an AI-driven assistant on my client
> that listens for me to say "Please take me off your call list" and blocks all
> future calls from that caller. It seems like the 608 use case would apply (for
> the case of false positive voice recognition), but since the definition here
> limits the intermediary to an entity "in the network," this scenario is out of
> scope. Should it be?

The key is “on my client.” In that case, the AI is acting directly on your behalf, so I could argue 607 is OK. I seriously doubt an average user would want to block a call and then say, “Even though my AI agent just blocked you, if you really want to get me, here’s my real phone number.”

I could imagine a developer pointing callers to the developer’s helpline if they thought the AI rejected them in error, which is not a possibility with 607. On the face of it, that sounds like a great idea. Who would not want to find out their application is not working well? However, I would think the privacy implications of such behavior would be beyond untenable. As a thought experiment, let us say that you put an AI on your phone from company G. Company G ‘innocently’ issues 608’s instead of 607’s, because if they get the speech recognition wrong, they would like to know about it. However, this results in a front-page article in The Intercept talking about how company G is pervasively monitoring user’s rejected calls by sending company G beacons every time a user’s call gets rejected, or at least when the calling party tries to remediate. Yuck.

So, even though in theory since a machine rejected the call (normally a 608), it is totally under your control. So, I’d offer 607 is still the right thing.

Do we need text to talk about this? It seems to be a way-out-there corner case that could have bad repercussions if implemented poorly.

[snip]

> = Section 4.1 =
> 
> Using "bitbucket" in the examples seems like it sends the wrong message about
> the utility of the contact address.

On the one hand, I might offer it is sending the reality message :-)
However, I’ll take my cynical hat off and fix it. Thanks!