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

[Denis Ovsienko <[e-mail]>]

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 : <[e-mail]>
To : <[e-mail]>
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  
 > >[e-mail] mailing lists by 2017-03-21. Exceptionally, comments may be  
 > >sent to [e-mail] 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