ietf
[Top] [All Lists]

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

2017-03-20 04:46:56
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 : <denis(_at_)ovsienko(_dot_)info>
To : <draft-ietf-sipcore-status-unwanted(_dot_)all(_at_)ietf(_dot_)org>
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 ----  
 
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  
ietf(_at_)ietf(_dot_)org mailing lists by 2017-03-21. Exceptionally, 
comments may be  
sent to iesg(_at_)ietf(_dot_)org 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.  
 
 
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


<Prev in Thread] Current Thread [Next in Thread>