Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard
Adam Roach <adam@nostrum.com> Tue, 21 March 2017 16:59 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C957D127201; Tue, 21 Mar 2017 09:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTL0lAzEhr68; Tue, 21 Mar 2017 09:59:31 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BB312708C; Tue, 21 Mar 2017 09:59:30 -0700 (PDT)
Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2LGxTTL063091 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Mar 2017 11:59:30 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local
To: Pete Resnick <presnick@qti.qualcomm.com>, ietf@ietf.org
References: <148893258669.17675.7013326933036466908.idtracker@ietfa.amsl.com> <E74825F1-B661-4A8C-9B96-CC970AEA0E56@qti.qualcomm.com>
Cc: draft-ietf-sipcore-status-unwanted@ietf.org, ben@nostrum.com, sipcore@ietf.org, sipcore-chairs@ietf.org
From: Adam Roach <adam@nostrum.com>
Message-ID: <534047ad-8971-88ec-3d16-254c766bbfa3@nostrum.com>
Date: Tue, 21 Mar 2017 11:59:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <E74825F1-B661-4A8C-9B96-CC970AEA0E56@qti.qualcomm.com>
Content-Type: multipart/alternative; boundary="------------D0FB48B24F913B613ECBEA3B"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/txLKNSF2vu7g3sizfjxjEQhvfN8>
Subject: Re: [sipcore] Last Call: <draft-ietf-sipcore-status-unwanted-04.txt> (A SIP Response Code for Unwanted Calls) to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 16:59:34 -0000
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. > 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. > 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 > 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
- [sipcore] Last Call: <draft-ietf-sipcore-status-u… The IESG
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Denis Ovsienko
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Dale R. Worley
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Paul Kyzivat
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Paul Kyzivat
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… A. Jean Mahoney
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Adam Roach
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Dale R. Worley
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Pete Resnick
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Henning Schulzrinne
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Ranjit Avasarala
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Pete Resnick
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Adam Roach
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Alan Johnston
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Pete Resnick
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Asveren, Tolga
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Pete Resnick
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Adam Roach
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Dale R. Worley
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Paul Kyzivat
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Dale R. Worley
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Dale R. Worley
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Souma Badombena
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Henning Schulzrinne
- Re: [sipcore] Last Call: <draft-ietf-sipcore-stat… Asveren, Tolga