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