Subject: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 07 Mar 2017 16:23:06 -0800

The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'A SIP Response Code for Unwanted Calls'
  <draft-ietf-sipcore-status-unwanted-04.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2017-03-21. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines the 666 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 20 Mar 2017 09:45:58 +0000

Dear IETF members,

if you can stop the publication below, please stop it now. If you cannot but know someone who can stop it, please ask them now to stop it. There is little time left because the last call for it ends tomorrow.

The goal of IETF is to make Internet better but this document is about to make it worse. A principle of IETF is rough consensus but this document and the implementations arising from it will be toxic for consensus.

This situation is effectively a test of how much sense we have.

============ Forwarded message ============
>From : <[email-masked]>
To : <[email-masked]>
Date : Fri, 17 Mar 2017 16:21:13 +0000
Subject : Re: Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard
============ Forwarded message ============
 > ---- On Wed, 08 Mar 2017 00:23:06 +0000 The IESG wrote ----  
 > >  
 > Dear fellow IETF contributors, 
 >  
 > Though draft-ietf-sipcore-status-unwanted is as far in its development as in a last call, there is a point that I believe to be important enough to be raised now. The matter is, it would be very wrong to publish this document with the SIP message code assigned as the number of the beast. 
 >  
 > First of all, this would be wrong because of the end users. The proposed status code will be exposed to the end user base of SIP, which is so large that even a fraction of it is still a large number of real people, so specific consequences must be considered. 
 >  
 > If you mind people that take the Bible and its teachings seriously, it will be easy for them to see it as a personal insult if their phone receives and displays the message as it is proposed, as well as if their phone sends such a message on their behalf. This is not specific to SIP, the same conflict may be caused by a snail mail post, except in real-time communications people have less time to think and step back from the situation. 
 >  
 > As an additional consideration, the document implies that the user receiving the "unwanted" call has a good reason and the user placing the call does not have it, as in spam calls. In the real everyday world it may also be the different way around, for instance, someone may be avoiding calls due to problems with debt, job, alcohol, drugs, whatever, and that someone will just use the biggest "blacklist" button their phone can offer, just because they fail to think. There are other situations where this message code will be used as a handy tool for insulting genuine callers. 
 >  
 > It would be best here not to pour any more gas into this flame, moreover that professional spammers and phishers don't really care how exactly the call was terminated. Whatever status code was returned, they will continue calling numbers from the list until the end of the shift. So this feature as it is proposed may make more damage to normal people rather than to those who seem to be originally targeted. 
 >  
 > Then, if the document gets published and implemented as it is and starts causing grief, eventually people will want to know how the number of the beast got assigned to the message, they will look the document up and see: 
 >  
 > "The particular response code number was chosen to reflect the distaste felt by many upon receiving such calls." 
 >  
 > Which reads "We just needed some number, so we had chosen the number of the beast to make this new feature look cool. We acknowledge this number conveys some particular concept to many people but we deliberately disregard any future side effects." 
 >  
 > This is the only way I can read it, and the only way many other people will be able to read it. This is a fact, please deal with it while you can. 
 >  
 > Hopefully this helps to explain another important aspect. 
 >  
 > Besides the end users, there is the technical audience, both inside and outside of IETF. This audience expects a certain level of professionalism from IETF Standard Track publications. By not meeting those expectations this publication would disappoint the engineers too and lower their motivation to contribute. Simply put, the number of people that think "IETF has less respect to its intended audience than I used to think. They don't make Internet better, they are whim-driven, now that I know it, I better stay away." will increase. And they will actually stay away regardless if things improve afterwards. 
 >  
 > It may seem excess, but let me remind that the world is full of people who are mentally unwell and are on the verge of losing control, to the bad luck of poor strangers that happen to be around at the time. Often it is a tiny thing that finally tips their mind over. You cannot do much about this fact. But you can avoid introducing another potential last straw with an IETF label on it. 
 >  
 > To sum it up, the current revision of the I-D is going to increase the long-term risk of damage to IETF if it is published. I am asking you to change the codepoint to an ordinary nondescript number or to cancel the publication soonest possible. 
 >  
 > Thank you. 
 >  
 > --  
 >  Denis Ovsienko 

-- 
    Denis Ovsienko

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 20 Mar 2017 10:23:00 -0400

Denis Ovsienko <[email-masked]> writes:
> If you mind people that take the Bible and its teachings seriously, it
> will be easy for them to see it as a personal insult if their phone
> receives and displays the message as it is proposed, as well as if
> their phone sends such a message on their behalf. This is not specific
> to SIP, the same conflict may be caused by a snail mail post, except
> in real-time communications people have less time to think and step
> back from the situation. 
 
That seems to be a valid consideration to me:  Embedding
culturally/religiously/politically symbolic identifiers in a protocol in
a way that end users will at least occasionally see is probably not a
good idea.  It's clear even to me that a flippant reference to the
Prophet is asking for trouble, and it seems like we should take
references to the Number of the Beast seriously, given its long history
as a politically powerful symbol.

> As an additional consideration, the document implies that the user
> receiving the "unwanted" call has a good reason and the user placing
> the call does not have it, as in spam calls.

I'm not current on the document, but my understanding is that it makes
clear that the response code is *in the opinion of the recipient* and
must be interpreted as such.  And indeed, that the recipient may have
triggered the response accidentally.

> Besides the end users, there is the technical audience, both inside
> and outside of IETF. This audience expects a certain level of
> professionalism from IETF Standard Track publications. By not meeting
> those expectations this publication would disappoint the engineers too
> and lower their motivation to contribute. Simply put, the number of
> people that think "IETF has less respect to its intended audience than
> I used to think. They don't make Internet better, they are
> whim-driven, now that I know it, I better stay away." will
> increase. And they will actually stay away regardless if things
> improve afterwards. 
 
I think the evidence is that seriousness is not required to attract
technical talent to the IETF.  (See RFCs 439, 527, 748, 968, 1097, 1149,
1216, 1217, 1313, 1437, 1438, 1605, 1606, 1607, 1776, 1882, 1924, 1925,
1926, 1927, 2100, 2321, 2322, 2323, 2324, 2325, 2410, 2549, 2550, 2551,
2795, 3091, 3092, 3093, 3251, 3252, 3514, 3751, 4041, 4042, 4824, 5241,
5242, 5513, 5514, 5841, 5984, 6214, 6217, 6592, 6593, 6919, 6921, 7168,
7169, 7511, and 7514.)  However, there might be a public relations
problem concerning management, politicians, etc.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2017 11:29:48 -0400

[Trimming the distribution to sipcore to minimize the disruption.]

Denis,

Do you have any expertise with SIP? I don't recall ever seeing your name 
before. Your comments exhibit a profound misunderstanding of it.

SIP response codes are almost never displayed to end users. For that 
matter they aren't even typically exposed to *operators* of SIP-based 
systems. Only when people are diagnosing signaling problems within the 
network are they visible. So the basic premise of your objection is 
ill-founded.

	Sincerely,
	Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2017 12:04:25 -0400

> as a politically powerful symbol.

I don't find it reasonable to cater to superstitious beliefs. (E.g. 
omitting the 13th floor from a building.)

OTOH, I will agree that the choice of 666 as the response code here was 
not incidental - it clearly was chosen with that "Number of the Beast" 
connotation in mind. In that sense the choice was gratuitous.

The requirement is that the number be of the form 6nn, and that it be 
one that has not already been assigned a meaning within the protocol. 
The process for assigning specific values for new response codes is ad hoc:

- sometimes the next unassigned value is assigned,
- sometimes sub-ranges are reserved for related values,
- sometimes a value is assigned based on a similar value
   in another category. (E.g. 406 and 606).

None of these would lead to 666 being an obvious choice in this case.

Hence, I would not object to choosing a different value based on such 
criteria.

BUT, should there ever be a need to assign another value in the 6nn 
range, and there is some rational reason (other than to explicitly 
reference the Number of the Beast), then I would strenuously object to 
objections based on this connotation of that particular value.

	Sincerely,
	Paul Kyzivat

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 20 Mar 2017 14:57:24 -0500

For some background - there was quite a bit of DISPATCH WG discussion on 
the use of the 666 response code to indicate that a call is unwanted, 
but it revolved around the use of a 6xx type of response vs. a 4xx 
response code.

How the choice might be presented to the end user was also discussed, 
although SIPCORE and DISPATCH WGs don't focus on GUI stuff. When the end 
user receives a call, they could select a "Block Caller" button on their 
cell phone just like they can select "Send to Voice Mail". The 
application on the phone would then generate the 666 response code, but 
the app would be very unlikely to show this code to the end user. On the 
caller's end, their app may not show them anything more than their call 
failed. Realistically, the response code would be seen only in diagnostics.

I took a look through the IETF archives for other uses of 666. 666 comes 
up occasionally in mailing list discussions as a foo/bar-type 
placeholder. RFC 7999 specifies the BGP community BLACKHOLE and its 
value, where "the low-order two octets in decimal are 666, a value 
commonly associated with BGP blackholing among network operators."

That said, there's plenty of space in the SIP 6xx response code range 
for an alternate response code to be selected if we think this will 
likely make end users uncomfortable.

Regards,

Jean

On 3/20/17 9:23 AM, Dale R. Worley wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 Mar 2017 18:26:30 -0500

[as chair]

> [Trimming the distribution to sipcore to minimize the disruption.] 

To be clear, this is an IETF LC comment. For better or worse (in 
practice, it's a mix of both), such conversations take place on the 
[email-masked] mailing list to ensure that the document has the consensus 
of the IETF as a whole, rather than just the consensus of their 
originating working group. I understand the desire to be less 
disruptive, but we also don't want to restrict the discussion to a 
smaller venue than is appropriate. Please direct future comments in this 
thread to the [email-masked] mailing list.

Thanks!

/a

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 20 Mar 2017 20:07:59 -0400

> likely make end users uncomfortable.

I must say that the alternative that comes immediately to my mind is
"668: The Neighbor of the Beast".

Dale

---

From: Pete Resnick <[email-masked]>
Date: Tue, 21 Mar 2017 10:49:54 -0500

I'm sorry to say that I do not think this mechanism is well thought out, 
I think it actually causes active harm to interoperability, and I think 
this document should be abandoned for a better (and simpler) solution to 
the problem, which I describe below.

I will note that I have not been following the discussion of this 
document except for it's introduction at the last plenary meeting, but I 
(and others) did give comments at that time that as far as I can tell 
were not taken into account. I did review the thread on the sipcore list 
regarding the difference between the new code and the 603 code. That 
thread does not address my concerns, and in fact in some way reinforces 
it. I have not reviewed other discussion on the list.

The purported purpose of this 666 mechanism is to allow additional 
semantics to be expressed beyond a simple 603 (Decline). That is a fine 
desire. However, instead of adding decent semantics to declining a call, 
666 adds only one additional bit of information to 603, and that one bit 
ends up causing more semantic ambiguity: The user has still declined the 
call (just as 603 would have), and has added that the call is *somehow* 
unwanted (so a provider *could* act to prevent such calls in the 
future), but the user has not indicated the *reason* they indicate the 
call is unwanted. Is it because they want to add this calling party to a 
call block list? Is it that they want to reject all calls of this 
particular class (cf. draft-ietf-sipcore-callinfo-spam)? Is there some 
other handling that would be appropriate given the particular reason the 
user has rejected the call? The best a provider is going to be able to 
do is guess. The document admits the ambiguity in the semantics, saying 
that the provider will have to use heuristics to guess at what the user 
really wants. We should not be introducing a new mechanism that only 
adds to the semantic ambiguity and might end up with results that the 
user might specifically not want in a particular case. What I think was 
really intended all along was to have un-upgraded implementations treat 
these rejections just like 603, but add some semantics that upgraded 
implementations can use to determine what ought to be done in the 
future.

The right solution, IMO, is to simply add a header to the 603 response 
that indicates what the user means by their declining, and gives a real 
indication of how handle such calls in the future. Call it 
"Decline-Type" for argument sake. Just like the Retry-After header adds 
semantics to indicate when the caller might want to try an identical 
call again, this new header will indicate that the user never wants a 
call from this particular caller again (e.g., "Decline-Type: 
block-caller", which the service provider can definitively use to add 
the caller to a block list), or that this caller and every caller with a 
similar type should be rejected (e.g. "Decline-Type: block-caller-type; 
type=political", which the provider could definitively use to reject 
similar calls in the future), etc.. With this, there's no need for a 
bunch of MAYs such that appear in section 4, you get an extensible 
mechanism that could be used by any 603 response. You also get the added 
bonus that un-upgraded entities will continue to treat this just like 
every other 603 without a Retry-After header, which is exactly what you 
want.

To be clear, the three things I am concerned about are:

1. The 666 mechanism leaves the decision of what is meant by "unwanted" 
to the provider, which will inevitably cause data loss through the use 
of heuristics. Adding a header to the 603 response is an extensible 
mechanism that could capture the single semantic bit of 666 *and any 
future semantics that one wishes to add*, without requiring the provider 
to guess. The provider gets definitive information that it can act on.

2. The 666 mechanism limits the implementation of the mechanism to a 
1-button choice and requires additional standardization work to use a 
different UI. Clearly 666 was designed around something akin to a "SPAM" 
button in the UI. But what if I want a field in my address book that 
says, "Permanently block this particular caller" (say, my ex-boyfriend 
or my annoying neighbor)? I don't want to indicate that these are spam 
calls because I don't want my provider applying heuristics to them. I 
want to send back a 603 with a header that says, "Block these whenever 
you see them, but only for me." I can think of all sorts of 
other-than-one-button UIs that someone might want to implement. 666 is 
tied to a particular UI. 603 with a header is extensible.

3. The 666 mechanism will be treated as a 600 "Busy" error by 
un-upgraded callers and/or providers. That might imply to some 
implementations that they should try to re-dial (e.g., the provider 
using the auto-redial feature) or to engage in other poor behavior. 603 
with no Retry-After header already has a semantic of "The call was 
rejected and I'm not telling you when a good time to call back is", so 
there is some hope that an un-upgraded caller is more likely to do the 
right thing.

Given the admittedly restricted review of the WG archive that I did, I 
didn't see anything to indicate that the WG fully considered the 
implications of 666 that I have outlined above. This is not simply a 
design preference; I believe the design of the proposed mechanism 
doesn't accomplish the goal and actually does some harm. Overall, 666 
damages interoperability by introducing an ambiguous piece of 
information, which will lead to potential data loss (i.e., improperly 
applied heuristics), and will require adding a header in the future in 
order to accomplish the real goal. Adding a header is a simple 
mechanism, accomplishes the desired task, has extensibility, and doesn't 
cause the problems that 666 does. Please reconsider this, drop this 
document, and replace it by adding real semantics to the 603 response 
with an extensible header. It's a quick document to write (a bunch of 
the text in the current document can be reused) and it will not suffer 
the problems that 666 introduces. Otherwise, we're going to be right 
back where were when we started, needing to add a mechanism so that the 
user can really indicate what they mean. This is the wrong solution.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Mar 2017 16:17:05 +0000

Pete,

I believe we discussed several of these issues in the meeting and the early in-person discussion, but the discussion was never quite focused, so it's probably easy to miss in the archives. My take of the discussion was that a simple mechanism that reflects plausible and likely UI approaches was preferable to a more complex mechanism. Nothing prevents adding information to the 'unwanted' status code in the future, should there be a need. As you indicate, the Call-Info labeling may well inform such an effort.

Yes, the idea was to model the (apparently near-universal) notions of the email spam button. Indeed, early phone UIs that are emerging do seem to take the same approach, such as the Google Android dialer UI. It offers exactly one option - swipe up to accept and a red (X) button to block calls like that.

The goal was never to create a full-fledged API for rejecting classes of calls or otherwise controlling the behavior of voice spam filters. I don't think that's appropriate for a call response as that would seem to be better done via a web interface or other API-based configuration option. For example, such web UIs may offer more in-depth options such as "no charities, except X" or "no surveys except those labeled as high-quality by trusted organization Y". I don't think we are anywhere close to knowing what this should be.

My sense is that, given UI and user patience limitations, no deployed system actually uses the Retry-After header, so all 603's seen in the wild are devoid of this indicator.

In practice, users will only be willing to spend a limited amount of time on feedback for unwanted calls. Analytics will be much better in sorting out the "annoying ex" from "annoying time share seller" than asking users to fill out a survey after the call - the former will be indicated by exactly one person only, the latter by hundreds or thousands. For what it's worth, the same potential problems exists in email, but doesn't seem to have caused any actual problems for spam filters since the statistical signature looks quite different.

Adding parameters to existing status codes can be done, but that seems more a matter of design taste. After all, we could then dispense with all specific codes and just use 100, 200, 400, 500 and 600, each with headers attached. This has not been the SIP design approach in the past. I don't see the problem with a new status code - we routinely add them and the mechanism of handling unknown ones are quite clear.

Henning

From: Pete Resnick [mailto:[email-masked]]
Sent: Tuesday, March 21, 2017 11:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Adam Roach <[email-masked]>; [email-masked]
Subject: Re: Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard

I'm sorry to say that I do not think this mechanism is well thought out, I think it actually causes active harm to interoperability, and I think this document should be abandoned for a better (and simpler) solution to the problem, which I describe below.

I will note that I have not been following the discussion of this document except for it's introduction at the last plenary meeting, but I (and others) did give comments at that time that as far as I can tell were not taken into account. I did review the thread on the sipcore list regarding the difference between the new code and the 603 code. That thread does not address my concerns, and in fact in some way reinforces it. I have not reviewed other discussion on the list.

The purported purpose of this 666 mechanism is to allow additional semantics to be expressed beyond a simple 603 (Decline). That is a fine desire. However, instead of adding decent semantics to declining a call, 666 adds only one additional bit of information to 603, and that one bit ends up causing more semantic ambiguity: The user has still declined the call (just as 603 would have), and has added that the call is somehow unwanted (so a provider could act to prevent such calls in the future), but the user has not indicated the reason they indicate the call is unwanted. Is it because they want to add this calling party to a call block list? Is it that they want to reject all calls of this particular class (cf. draft-ietf-sipcore-callinfo-spam)? Is there some other handling that would be appropriate given the particular reason the user has rejected the call? The best a provider is going to be able to do is guess. The document admits the ambiguity in the semantics, saying that the provider will have to use heuristics to guess at what the user really wants. We should not be introducing a new mechanism that only adds to the semantic ambiguity and might end up with results that the user might specifically not want in a particular case. What I think was really intended all along was to have un-upgraded implementations treat these rejections just like 603, but add some semantics that upgraded implementations can use to determine what ought to be done in the future.

The right solution, IMO, is to simply add a header to the 603 response that indicates what the user means by their declining, and gives a real indication of how handle such calls in the future. Call it "Decline-Type" for argument sake. Just like the Retry-After header adds semantics to indicate when the caller might want to try an identical call again, this new header will indicate that the user never wants a call from this particular caller again (e.g., "Decline-Type: block-caller", which the service provider can definitively use to add the caller to a block list), or that this caller and every caller with a similar type should be rejected (e.g. "Decline-Type: block-caller-type; type=political", which the provider could definitively use to reject similar calls in the future), etc.. With this, there's no need for a bunch of MAYs such that appear in section 4, you get an extensible mechanism that could be used by any 603 response. You also get the added bonus that un-upgraded entities will continue to treat this just like every other 603 without a Retry-After header, which is exactly what you want.

1.    The 666 mechanism leaves the decision of what is meant by "unwanted" to the provider, which will inevitably cause data loss through the use of heuristics. Adding a header to the 603 response is an extensible mechanism that could capture the single semantic bit of 666 and any future semantics that one wishes to add, without requiring the provider to guess. The provider gets definitive information that it can act on.

2.    The 666 mechanism limits the implementation of the mechanism to a 1-button choice and requires additional standardization work to use a different UI. Clearly 666 was designed around something akin to a "SPAM" button in the UI. But what if I want a field in my address book that says, "Permanently block this particular caller" (say, my ex-boyfriend or my annoying neighbor)? I don't want to indicate that these are spam calls because I don't want my provider applying heuristics to them. I want to send back a 603 with a header that says, "Block these whenever you see them, but only for me." I can think of all sorts of other-than-one-button UIs that someone might want to implement. 666 is tied to a particular UI. 603 with a header is extensible.

3.    The 666 mechanism will be treated as a 600 "Busy" error by un-upgraded callers and/or providers. That might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior. 603 with no Retry-After header already has a semantic of "The call was rejected and I'm not telling you when a good time to call back is", so there is some hope that an un-upgraded caller is more likely to do the right thing.

Given the admittedly restricted review of the WG archive that I did, I didn't see anything to indicate that the WG fully considered the implications of 666 that I have outlined above. This is not simply a design preference; I believe the design of the proposed mechanism doesn't accomplish the goal and actually does some harm. Overall, 666 damages interoperability by introducing an ambiguous piece of information, which will lead to potential data loss (i.e., improperly applied heuristics), and will require adding a header in the future in order to accomplish the real goal. Adding a header is a simple mechanism, accomplishes the desired task, has extensibility, and doesn't cause the problems that 666 does. Please reconsider this, drop this document, and replace it by adding real semantics to the 603 response with an extensible header. It's a quick document to write (a bunch of the text in the current document can be reused) and it will not suffer the problems that 666 introduces. Otherwise, we're going to be right back where were when we started, needing to add a mechanism so that the user can really indicate what they mean. This is the wrong solution.

pr
--
Pete Resnick http://www.qualcomm.com/~presnick/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.qualcomm.com_-257Epresnick_&d=DwMFAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ZsmZFFMTXYB11wQOAzumSkgmvAzLj_2Hn4Z58HTMBvE&s=tlEJ9fjpmuZLfEjlkXtf4tDxw4Bni6wK1arhT_2Zddg&e=>
Qualcomm Technologies, Inc. - +1 (858)651-4478

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2017-03-21. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=DwMFAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ZsmZFFMTXYB11wQOAzumSkgmvAzLj_2Hn4Z58HTMBvE&s=hy8D0YsflQHIyKQiWo_fdbP4Ah_Ej6vFervxifuVyJU&e=>

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ballot/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_ballot_&d=DwMFAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=ZsmZFFMTXYB11wQOAzumSkgmvAzLj_2Hn4Z58HTMBvE&s=kX6Ocb3l9f7SR-kaqL7gkLgF0bj11sm1YalrviswYQY&e=>

---

From: Ranjit Avasarala <[email-masked]>
Date: Tue, 21 Mar 2017 11:24:32 -0500

Hi Pete
y
I quite agree with you.  Instead of proposing a new response code like 666,
it would be better to add or rather propose a new header and add it to 603
response.

Regards
Ranjit

On Tue, Mar 21, 2017 at 10:49 AM, Pete Resnick <[email-masked]>
wrote:

> I'm sorry to say that I do not think this mechanism is well thought out, I
> think it actually causes active harm to interoperability, and I think this
> document should be abandoned for a better (and simpler) solution to the
> problem, which I describe below.
>
> I will note that I have not been following the discussion of this document
> except for it's introduction at the last plenary meeting, but I (and
> others) did give comments at that time that as far as I can tell were not
> taken into account. I did review the thread on the sipcore list regarding
> the difference between the new code and the 603 code. That thread does not
> address my concerns, and in fact in some way reinforces it. I have not
> reviewed other discussion on the list.
>
> unwanted (so a provider *could* act to prevent such calls in the future),
> but the user has not indicated the *reason* they indicate the call is
> unwanted. Is it because they want to add this calling party to a call block
> list? Is it that they want to reject all calls of this particular class
> (cf. draft-ietf-sipcore-callinfo-spam)? Is there some other handling that
> would be appropriate given the particular reason the user has rejected the
> call? The best a provider is going to be able to do is guess. The document
> admits the ambiguity in the semantics, saying that the provider will have
> to use heuristics to guess at what the user really wants. We should not be
> introducing a new mechanism that only adds to the semantic ambiguity and
> might end up with results that the user might specifically not want in a
> particular case. What I think was really intended all along was to have
> un-upgraded implementations treat these rejections just like 603, but add
> some semantics that upgraded implementations can use to determine what
> ought to be done in the future.
>
> indication of how handle such calls in the future. Call it "Decline-Type"
> for argument sake. Just like the Retry-After header adds semantics to
> indicate when the caller might want to try an identical call again, this
> new header will indicate that the user never wants a call from this
> particular caller again (e.g., "Decline-Type: block-caller", which the
> service provider can definitively use to add the caller to a block list),
> or that this caller and every caller with a similar type should be rejected
> (e.g. "Decline-Type: block-caller-type; type=political", which the provider
> could definitively use to reject similar calls in the future), etc.. With
> this, there's no need for a bunch of MAYs such that appear in section 4,
> you get an extensible mechanism that could be used by any 603 response. You
> also get the added bonus that un-upgraded entities will continue to treat
> this just like every other 603 without a Retry-After header, which is
> exactly what you want.
>
>    1.
>    The 666 mechanism leaves the decision of what is meant by "unwanted"
>    to the provider, which will inevitably cause data loss through the use of
>    heuristics. Adding a header to the 603 response is an extensible mechanism
>    that could capture the single semantic bit of 666 *and any future
>    semantics that one wishes to add*, without requiring the provider to
>    guess. The provider gets definitive information that it can act on.
>    2.
>
>    The 666 mechanism limits the implementation of the mechanism to a
>    button in the UI. But what if I want a field in my address book that says,
>    "Permanently block this particular caller" (say, my ex-boyfriend or my
>    annoying neighbor)? I don't want to indicate that these are spam calls
>    because I don't want my provider applying heuristics to them. I want to
>    send back a 603 with a header that says, "Block these whenever you see
>    them, but only for me." I can think of all sorts of other-than-one-button
>    UIs that someone might want to implement. 666 is tied to a particular UI.
>    603 with a header is extensible.
>    3.
>
>    The 666 mechanism will be treated as a 600 "Busy" error by un-upgraded
>    callers and/or providers. That might imply to some implementations that
>    they should try to re-dial (e.g., the provider using the auto-redial
>    feature) or to engage in other poor behavior. 603 with no Retry-After
>    header already has a semantic of "The call was rejected and I'm not telling
>    you when a good time to call back is", so there is some hope that an
>    un-upgraded caller is more likely to do the right thing.
>
> implications of 666 that I have outlined above. This is not simply a design
> preference; I believe the design of the proposed mechanism doesn't
> accomplish the goal and actually does some harm. Overall, 666 damages
> interoperability by introducing an ambiguous piece of information, which
> will lead to potential data loss (i.e., improperly applied heuristics), and
> will require adding a header in the future in order to accomplish the real
> goal. Adding a header is a simple mechanism, accomplishes the desired task,
> has extensibility, and doesn't cause the problems that 666 does. Please
> reconsider this, drop this document, and replace it by adding real
> semantics to the 603 response with an extensible header. It's a quick
> document to write (a bunch of the text in the current document can be
> reused) and it will not suffer the problems that 666 introduces. Otherwise,
> we're going to be right back where were when we started, needing to add a
> mechanism so that the user can really indicate what they mean. This is the
> wrong solution.
>
> pr
> --
> Pete Resnick http://www.qualcomm.com/~presnick/
> Qualcomm Technologies, Inc. - +1 (858)651-4478 <(858)%20651-4478>
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 21 Mar 2017 11:51:42 -0500

Just replying to the points in your message (trimming as I go along):

On 21 Mar 2017, at 11:17, Henning Schulzrinne wrote:

> My take of the discussion was that a simple mechanism that reflects 
> plausible and likely UI approaches was preferable to a more complex 
> mechanism.

First, there is nothing complex about adding a header that says, 
"Decline-Type: spam" to 603. It is extremely simple, accomplishes 
exactly the same result, reflects the one envisioned plausible and 
likely UI, and has the added advantage of extensibility.

> Nothing prevents adding information to the 'unwanted' status code in 
> the future, should there be a need. As you indicate, the Call-Info 
> labeling may well inform such an effort.

The problem there is that you then will have two different ways of 
expressing "spam", adding yet more ambiguity. It means that the 
implementer has to know whether they're talking to a 666 implementation 
that does or does not know about the additional parameter to understand 
what the behavior will be. We've constantly faced this problem in IMAP 
over the years and it's made for horrible implementations.

Better to do the simple thing first and not end up with two incompatible 
ways to do the same thing in the future.

> Yes, the idea was to model the (apparently near-universal) notions of 
> the email spam button.

Simply achievable with 603 and "Decline-Type: spam". The only additional 
complexity is to create the IANA registry for future decline types. I'm 
only suggesting this document defining the one right now.

> The goal was never to create a full-fledged API for rejecting classes 
> of calls or otherwise controlling the behavior of voice spam filters.

Nor am I proposing such an API. Sure, pieces of this (and Call-Info 
labeling) might be useful for such a thing later, but I have no interest 
in such a thing now.

> In practice, users will only be willing to spend a limited amount of 
> time on feedback for unwanted calls.

Again, the mechanism I propose does not add to that limited time. It 
functions, in that scenario, exactly like 666. The difference is only in 
extensibility (and avoids the potential pitfalls I mentioned earlier).

> Adding parameters to existing status codes can be done, but that seems 
> more a matter of design taste.

As I said quite clearly, it's not a design matter. Using a separate 
status code to mean "decline, with additional semantics" has side 
effects, because you already have a status code for decline. Please 
re-read my explanation.

> After all, we could then dispense with all specific codes and just use 
> 100, 200, 400, 500 and 600, each with headers attached.

No, that absolutely does not follow. A layered approach of status codes 
for broader semantic values and headers for specialized processing works 
incredibly well. The problem arises when you introduce a status code 
that does not give the basic processing engine enough information to go 
on.

What you want in this case is to have the default behavior be "decline", 
as per the status code, and then have some side processing to figure out 
whether to deposit information into a spam analysis engine, or hand it 
off to some other process that does different sorts of things, based on 
the additional semantic information in the header. That's a good 
division of labor.

> I don't see the problem with a new status code - we routinely add them 
> and the mechanism of handling unknown ones are quite clear.

Please see my earlier comments on this particular status code: It 
increases semantic ambiguity, it increases the possibility for data 
loss, and it limits future extensibility.

Again, it's not clear that you've fully understood and considered what I 
wrote.

pr

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Mar 2017 11:59:23 -0500

On 3/21/17 10:49, Pete Resnick wrote:
>
> 1.
>
>     The 666 mechanism leaves the decision of what is meant by
>     "unwanted" to the provider, which will inevitably cause data loss
>     through the use of heuristics. Adding a header to the 603 response
>     is an extensible mechanism that could capture the single semantic
>     bit of 666 /and any future semantics that one wishes to add/,
>     without requiring the provider to guess. The provider gets
>     definitive information that it can act on.
>

The problem is that the semantics of 666 are backwards from the 
semantics of 603.

603 means "there is an issue with the disposition of the *called* party 
that prevents completing the call."

666 means "there is an issue with the disposition of the *calling* party 
that prevents completing the call."

You're proposing conflating the two semantics, which necessarily 
introduces more ambiguity, not less.

Carrier determination of how to handle these codes is, as with any 
nuisance communication mitigation, going to necessarily be based on 
heuristics to avoid accidental blacklisting, intentional blowback, and 
the inevitable gaming of the system by bad actors. You imply that the 
application of heuristics is an unwanted side effect of the system, when 
it in fact the primary goal.

In terms of being able to provide gradation between types of unwanted 
calls, the application of a header -- as you propose -- to provide such 
indication seems like a fine idea. I will point out one caveat and make 
one observation. The caveat is that it would be harmful to add this 
header in a way that reverses the sense of a response code, such as 
making 603 bear on the calling party rather than the called party; so 
such an indication would need to be on a new response code, such as the 
one currently proposed in draft-ietf-sipcore-status-unwanted. The 
observation is that this mechanism can be added to this new status at a 
later date, in a modular fashion and in a backwards compatible way. In 
other words: your proposed enhancement is *nice*, but it does not 
preclude publishing the mechanism currently described.

>     1-button choice and requires additional standardization work to
>     use a different UI. Clearly 666 was designed around something akin
>     to a "SPAM" button in the UI. But what if I want a field in my
>     address book that says, "Permanently block this particular caller"
>     (say, my ex-boyfriend or my annoying neighbor)? I don't want to
>     indicate that these are spam calls because I don't want my
>     provider applying heuristics to them. I want to send back a 603
>     with a header that says, "Block these whenever you see them, but
>     only for me." I can think of all sorts of other-than-one-button
>     UIs that someone might want to implement. 666 is tied to a
>     particular UI. 603 with a header is extensible.
>

That kind of persistent, hard-state user account configuration *really* 
isn't a reasonable kind of thing to do with a SIP status code (not least 
of all because you would need some mechanism for reviewing and managing 
such a list; and whatever that mechanism is could just as readily be 
used for adding entries). If you feel the need to pursue the somewhat 
related problem space of a network-assisted blocklist, we have a variety 
of tools we could bring to bear, such as XCAP. That's a separable 
problem, though, and I think that tangling it up with spam mitigation is 
a huge mistake.

I'll also point out that devices are perfectly capable of handling this 
feature locally without any assistance from the network, so I'm not sure 
how much value would be added by defining a network-hosted version of 
the service. The overarching point, though, is that a SIP response code 
is absolutely the wrong approach for doing so.

> 3.
>
>     The 666 mechanism will be treated as a 600 "Busy" error by
>     implementations that they should try to re-dial (e.g., the
>     provider using the auto-redial feature) or to engage in other poor
>     behavior. 603 with no Retry-After header already has a semantic of
>     "The call was rejected and I'm not telling you when a good time to
>     call back is", so there is some hope that an un-upgraded caller is
>     more likely to do the right thing.
>

This is really reaching, and I think is based on a misperception of how 
SIP clients actually work when they receive 6xx responses. Taken to its 
logical conclusion, if we accept your assertion then we can't ever 
define a new 6xx-class SIP response code for fear that such codes "might 
imply to some implementations that they should try to re-dial (e.g., the 
provider using the auto-redial feature) or to engage in other poor 
behavior."

/a

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Mar 2017 10:05:49 -0700

Pete,

Joining this conversation late - apologies if it has already been discussed.

If you are proposing using a SIP response code  603 and with a header field
Decline-Type: spam, the problem with this is that in SIP, failure responses
(non-2xx) are delivered hop-by-hop and not end-to-end.  This means that
although the first hop (proxy) will get the Decline-Type:spam header field,
any future hops will not.  Instead, they will just get the 603.

A different response code such as 666 will be conveyed end-to-end, so every
proxy and the calling UA will get the semantics.

- Alan -

On Tue, Mar 21, 2017 at 9:51 AM, Pete Resnick <[email-masked]>
wrote:

> "Decline-Type: spam" to 603. It is extremely simple, accomplishes exactly
> the same result, reflects the one envisioned plausible and likely UI, and
> has the added advantage of extensibility.
>
> Nothing prevents adding information to the 'unwanted' status code in the
>> future, should there be a need. As you indicate, the Call-Info labeling may
>> well inform such an effort.
>>
>
> expressing "spam", adding yet more ambiguity. It means that the implementer
> has to know whether they're talking to a 666 implementation that does or
> does not know about the additional parameter to understand what the
> behavior will be. We've constantly faced this problem in IMAP over the
> years and it's made for horrible implementations.
>
> Yes, the idea was to model the (apparently near-universal) notions of the
>> email spam button.
>>
>
> The goal was never to create a full-fledged API for rejecting classes of
>> calls or otherwise controlling the behavior of voice spam filters.
>>
>
> labeling) might be useful for such a thing later, but I have no interest in
> such a thing now.
>
> In practice, users will only be willing to spend a limited amount of time
>> on feedback for unwanted calls.
>>
>
> As I said quite clearly, it's not a design matter. Using a separate status
> code to mean "decline, with additional semantics" has side effects, because
> you already have a status code for decline. Please re-read my explanation.
>
> incredibly well. The problem arises when you introduce a status code that
> does not give the basic processing engine enough information to go on.
>
> whether to deposit information into a spam analysis engine, or hand it off
> to some other process that does different sorts of things, based on the
> additional semantic information in the header. That's a good division of
> labor.
>
> I don't see the problem with a new status code - we routinely add them and
>> the mechanism of handling unknown ones are quite clear.
>>
>
> increases semantic ambiguity, it increases the possibility for data loss,
> and it limits future extensibility.
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 21 Mar 2017 12:14:10 -0500

Just on a couple of small points:

On 21 Mar 2017, at 11:59, Adam Roach wrote:

> 603 means "there is an issue with the disposition of the *called* 
> party that prevents completing the call."

That's not how 603 is described in 3261. It can be used to express that 
"the user explicitly does not wish to ... participate." Whether that's 
based on being in the shower or not liking the number in the caller id 
or something else, it expresses the called party's decision not to take 
the call.

> 666 means "there is an issue with the disposition of the *calling* 
> party that prevents completing the call."

That's not how the mechanism is described in this document. It is not 
that you send back 666 when the system determines something about the 
calling party; you send back 666 when the called party says something 
(in this case "SPAM!") that indicates that the called party declined the 
call.

I disagree that the semantics are different.

> ...I think is based on a misperception of how SIP clients actually 
> work when they receive 6xx responses.

I think this is a fair criticism insofar as I agree that either 666 or a 
header on 603 will work equally in today's usage scenarios. My only 
response is that I have rosy glasses looking to future advances that 
might make us regret having painted ourselves into a corner.

pr

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 21 Mar 2017 17:41:14 +0000

FWIW (and considering that we may end up with a “rough consensus”), I agree with Adam’s analysis below.

So, overall I do not think any changes are needed in the draft and it can proceed to become a RFC.

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, March 21, 2017 12:59 PM
To: Pete Resnick <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard

The problem is that the semantics of 666 are backwards from the semantics of 603.

603 means "there is an issue with the disposition of the *called* party that prevents completing the call."

666 means "there is an issue with the disposition of the *calling* party that prevents completing the call."

You're proposing conflating the two semantics, which necessarily introduces more ambiguity, not less.

Carrier determination of how to handle these codes is, as with any nuisance communication mitigation, going to necessarily be based on heuristics to avoid accidental blacklisting, intentional blowback, and the inevitable gaming of the system by bad actors. You imply that the application of heuristics is an unwanted side effect of the system, when it in fact the primary goal.

In terms of being able to provide gradation between types of unwanted calls, the application of a header -- as you propose -- to provide such indication seems like a fine idea. I will point out one caveat and make one observation. The caveat is that it would be harmful to add this header in a way that reverses the sense of a response code, such as making 603 bear on the calling party rather than the called party; so such an indication would need to be on a new response code, such as the one currently proposed in draft-ietf-sipcore-status-unwanted. The observation is that this mechanism can be added to this new status at a later date, in a modular fashion and in a backwards compatible way. In other words: your proposed enhancement is *nice*, but it does not preclude publishing the mechanism currently described.

  1.  The 666 mechanism limits the implementation of the mechanism to a 1-button choice and requires additional standardization work to use a different UI. Clearly 666 was designed around something akin to a "SPAM" button in the UI. But what if I want a field in my address book that says, "Permanently block this particular caller" (say, my ex-boyfriend or my annoying neighbor)? I don't want to indicate that these are spam calls because I don't want my provider applying heuristics to them. I want to send back a 603 with a header that says, "Block these whenever you see them, but only for me." I can think of all sorts of other-than-one-button UIs that someone might want to implement. 666 is tied to a particular UI. 603 with a header is extensible.

That kind of persistent, hard-state user account configuration *really* isn't a reasonable kind of thing to do with a SIP status code (not least of all because you would need some mechanism for reviewing and managing such a list; and whatever that mechanism is could just as readily be used for adding entries). If you feel the need to pursue the somewhat related problem space of a network-assisted blocklist, we have a variety of tools we could bring to bear, such as XCAP. That's a separable problem, though, and I think that tangling it up with spam mitigation is a huge mistake.

I'll also point out that devices are perfectly capable of handling this feature locally without any assistance from the network, so I'm not sure how much value would be added by defining a network-hosted version of the service. The overarching point, though, is that a SIP response code is absolutely the wrong approach for doing so.

  1.  The 666 mechanism will be treated as a 600 "Busy" error by un-upgraded callers and/or providers. That might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior. 603 with no Retry-After header already has a semantic of "The call was rejected and I'm not telling you when a good time to call back is", so there is some hope that an un-upgraded caller is more likely to do the right thing.

This is really reaching, and I think is based on a misperception of how SIP clients actually work when they receive 6xx responses. Taken to its logical conclusion, if we accept your assertion then we can't ever define a new 6xx-class SIP response code for fear that such codes "might imply to some implementations that they should try to re-dial (e.g., the provider using the auto-redial feature) or to engage in other poor behavior."

/a

---

From: Pete Resnick <[email-masked]>
Date: Tue, 21 Mar 2017 12:43:28 -0500

> proxy and the calling UA will get the semantics.

Adam walked me through the last few paragraphs of 3261 section 6. It's 
not clear in that text whether proxies will or won't preserve the 
headers, but if they don't, I expect that's a showstopper for my 
proposal. That's a bummer, because I do think the status code is going 
to cause future heartburn. However, if you SIP folks conclude that the 
header will not get through proxies (and I will take you all at your 
word if you so conclude), and this mechanism does need to survive 
proxies (which I suspect it does), then I think we're stuck with the 
status code.

If so, I will happily return to you all to your discussion of whether 
particular numbers do or do not belong in IETF specifications. :-) (For 
the record, I thought 451 set a poor precedent, but I'm a curmudgeon.)

pr

---

From: Adam Roach <[email-masked]>
Date: Tue, 21 Mar 2017 12:49:26 -0500

On 3/21/17 12:43, Pete Resnick wrote:
> Adam walked me through the last few paragraphs of 3261 section 6.

To be clear (and this is an easy mistake to make, since the sections and 
their contained steps are huge), Pete is referring to the long-form 
version of step 6 in section 16.7 here. See RFC 3261, page 111.

/a

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 21 Mar 2017 15:51:52 -0400

> version of step 6 in section 16.7 here. See RFC 3261, page 111.

Ah, there's a tension between this paragraph:

         The stateful proxy MUST choose the "best" final response among
         those received and stored in the response context.

and this one:

         3-6xx responses are delivered hop-by-hop.  When issuing a 3-6xx
         response, the element is effectively acting as a UAS, issuing
         its own response, usually based on the responses received from
         downstream elements.  An element SHOULD preserve the To tag
         when simply forwarding a 3-6xx response to a request that did
         not contain a To tag.

But if many implementations take "choose the best final response" to
mean only re-sending the response code, we have a problem.

OTOH, it's quite possible to reserve a *set* of 6xx response codes to
carry the decline-type.  The only allocated 6xx responses are 600
(generic), 603, 604, and 606.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Mar 2017 18:05:37 -0400

Isn't it assumed that a Reason header is preserved e2e with error responses?

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 27 Mar 2017 14:15:17 -0400

> Isn't it assumed that a Reason header is preserved e2e with error responses?

Watching Roland's presentation in the Dispatch WG today prodded me to
think about this again.

As far as I can tell, RFC 3326 envisions that Reason headers can be
included in responses but doesn't specify how they are processed.  OTOH,
it seems to me that the odds are good that most proxies propagate
backward Reason headers in failure responses, so Reason would be a good
choice for carrying additional information.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 30 Mar 2017 16:31:29 -0400

> choice for carrying additional information.

Actually, if/when we define a "protocol" value for Response to be used
with "666" responses, we should just add a normative change to 3261 that
when a proxy chooses as "best response" a response with a Reason header,
it must propagate the Reason header.

Dale