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

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Tue, 11 Jun 2019 09:17:00 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-sipcore-rejected-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

= Section 3.5 =

"It is
   important to note the network element should be mindful of the media
   type requested by the UAC as it formulates the announcement.  For
   example, it would make sense for an INVITE that only indicated audio
   codecs in the Session Description Protocol (SDP) [RFC4566] to result
   in an audio announcement.  However, if the INVITE only indicated a
   real-time text codec and the network element can render the
   information in the requested media format, the network element MUST
   send the information in a text format, not an audio format."

I think the normative guidance here could be crisper, e.g., replacing the first
sentence with "The network element SHOULD use a media format for its
announcement for which the caller indicates support, if possible." I also don't
understand why the second example uses normative MUST but the first example
doesn't use normative language at all.

= Section 4.1 =

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

---

From: Eric Burger <[email-masked]>
Date: Wed, 19 Jun 2019 22:41:43 -0400

inline

> On Jun 11, 2019, at 12:17 PM, Alissa Cooper via Datatracker <[email-masked]> wrote:
> 

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]

> 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!

---

From: Eric Burger <[email-masked]>
Date: Wed, 19 Jun 2019 22:51:42 -0400

My bad - I forgot all the CC’s.

> On Jun 19, 2019, at 10:41 PM, Eric Burger <[email-masked]> wrote:
> 
> inline
> 
>> On Jun 11, 2019, at 12:17 PM, Alissa Cooper via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>>