Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Apr 2017 00:55:20 +0000

Ben,

thanks for the comments. Responses inline below, split into parts.

________________________________
From: sipcore <[email-masked]> on behalf of Ben Campbell <[email-masked]>
Sent: Tuesday, March 7, 2017 6:42 PM
To: [email-masked]; SIPCORE
Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-status-unwanted-04

Hi,

This is my AD evaluation of draft-ietf-sipcore-status-unwanted-04. I
have a few substantive and and some editorial comments. I don't think
any of these need block the IETF last call, which I will request
shortly. These can be resolved along with any IETF LC comments.

- Editorial Comments:

-- There's some general imprecision in the use of "UAC" and "UAS". I
think the intent is to speak of the UAC and UAS in the context of the
dialog-initiating transaction (at least when a dialog is involved), but
it ends up with language of the form of "... when the UAS sends a BYE
request...". Perhaps terms like "caller UA" and "callee UA" would be
more clear? (Not that I particularly those, when caller and callee or
called vary by a single letter.)

I used calling and called party user agent to avoid the one-letter hamming distance. I think I have removed all UAS reference.

-- section 1, first paragraph, sentence starting with "This document
addresses only the last mode..."
The sentence is convoluted. Can it be broken into  a few simpler
sentences?

I broke the sentence and paragraph into smaller, more readily-digestible, pieces.

-- 4, 2nd paragraph:
Please avoid 2119 keywords (in this case MAY), in a non-exhaustive list
of examples, as it implies that additional MAYs exist but are not
explicitly mentioned. Consider something along the lines of "...MAY
perform some action based on local policy, for example, add the party to
a local blacklist, ..."

The service provider delivering calls or messages to the user issuing the response MAY take actions, for example, ... (without MAYs).

--4, 4th paragraph: I'm not sure I believe the sentence starting with
"In other words" paraphrases any previous words :-)

Two thoughts got commingled. Separated into two paragraphs and no more other words.

--6: 2nd to last paragraph: A citation for call transfer might be nice.
(Maybe the call flows RFC?)

Citation added.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Apr 2017 20:01:35 -0500

All sounds good, subject to seeing things in situ.

Thanks!

Ben.

> On Apr 20, 2017, at 7:55 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> Ben,
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Apr 2017 20:03:37 -0500

Thanks!

Ben.

> On Apr 20, 2017, at 7:55 PM, Henning Schulzrinne <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Ben,
> 
> From: sipcore <[email-masked] <mailto:[email-masked]>> on behalf of Ben Campbell <[email-masked]>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Apr 2017 01:34:06 +0000

Ben,

More inline.

- Substantive Comments:

-- section 4, first paragraph:

I'm struggling to understand what a sending a 666 when canceling a
branch of a forked call would mean. Are we talking about a scenario
where a forking proxy notes that one device responds with a 666, then
the proxy sends that to the other branches? If so, some elaboration of
the use case might be helpful.

This is based on the list discussion, so I'm not 100% sure, but my take is along the lines you state:

A forking proxy sends the robocall INVITE. One of the branches responds with an 'unwanted', triggering the forking proxy to send a CANCEL with a Reason header with the 'unwanted' status, so that the other UAs will know why the phone stopped ringing. (They might even show some appropriate indication in the user interface, such as "You fool just jumped out of the shower to answer a call about time share condos, but fortunately somebody else in your household already hung up on the bozo." Or something like that.)

I've tweaked the wording, but let me know if this needs to be split into separate cases.

The response code MAY also be used as the value of the "cause" parameter of a SIP reason-value in a Reason header field <xref target="RFC3326"/>, typically when the called party user agent issues a BYE request terminating an incoming call or a forking proxy issues a CANCEL request after receiving a 607 response from one of the branches.

-- Section 4, paragraph 3:
There's some imprecision in whether explicit user action is expected
when deciding to send a 666. I think the intent is that explicit user
action (e.g. a spam button) is just one of multiple ways a called UA
could decide to do so. But the last sentence of the paragraph seems to
indicate an expectation for explicit UI action, in spite of the earlier
sentences that allowed otherwise. It's not clear to me if those previous
sentences describe when to _send_ a 666, or just what one might do when
receiving one.

This is confusing since the paragraph talks about two different things, namely the general behavior of SIP elements when dealing with flagged calls, and the UI that may trigger the response. I'll break this into two paragraphs.

However, I'm struggling a bit to reword this since, even if the UA uses some local rules to auto-trigger an 'unwanted' response, the user experience is indeed the same as the spam button - something may happen, but the details are left to the implementation.

-6, 3rd paragraph from end:
How can one reasonably know that an identity has been reassigned? I can
see the case where the callee's service provider is the same as the
caller's service provider, but that's a degenerate case. Are we
expecting the calling SP to inform the callee SP out of band, and the
callee SP to believe them? Given how poorly that seems to work in the
context of email, I wonder if there's any useful advice to give here.

There are actually companies that track service terminations for numbers (they get lists from the major mobile providers), as that matters for making sure that any consent the previous holder of the number gave to be called is still valid. There have been court cases where a utility called a delinquent customer repeatedly - except the number of that customer had been re-assigned to some unlucky new person. This is obviously far beyond the scope of the draft, but I'll try to elaborate a bit.