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
On 3/20/17 5:45 AM, Denis Ovsienko wrote:
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