From nobody Tue Oct 4 11:01:08 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3C129405 for ; Tue, 4 Oct 2016 11:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 GRRR8v20THUd for ; Tue, 4 Oct 2016 11:01:06 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69FF11293FF for ; Tue, 4 Oct 2016 11:01:05 -0700 (PDT) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-12v.sys.comcast.net with SMTP id rU1Rb48ErlHMYrU1Yb6M6L; Tue, 04 Oct 2016 18:01:04 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-po-03v.sys.comcast.net with SMTP id rU1Wbgr0nDbf9rU1XbbRrh; Tue, 04 Oct 2016 18:01:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u94I11K9006119; Tue, 4 Oct 2016 14:01:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u94I11Gl006102; Tue, 4 Oct 2016 14:01:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Henning Schulzrinne In-Reply-To: (Henning.Schulzrinne@fcc.gov) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 04 Oct 2016 14:01:00 -0400 Message-ID: <87pongvvs3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfDsQn1vdYc+gZ9h/PsofNEbAjgirT8yoIvS0lELtHy+PFdR+pro9AG7PQ72wxrebwLAYLa6qiAppMHAhld/J6Uj14HelqiSHmzq9smwhwLATGFT0j6cK NjZq21SXbwSItKrQ+M2nChSOWov9hGFdC7yg5ixQW1iRTI0hg19H2DiYzj3fuXjQihDmIhKWiD71d4jTl9WeSn+/MTARlGdLuHc= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 18:01:08 -0000 Henning Schulzrinne writes: > https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted/ > > https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ 1. I like the symbolism of using 666 as a response code, but 6xx codes are generally a bad idea because they require one UAC to assert a fact about all the other possible destinations of the INVITE, which the UAC cannot know. (See draft-worley-6xx-considered-harmful.) So it should be a 4xx response code. 2. draft-schulzrinne-dispatch-callinfo-spam says: If the entity inserting the header field does not have information it wants to link to, it MUST use an empty data URL [RFC2397] as a placeholder, as in "data:". (The Call-Info header field syntax makes the URI itself mandatory.) That's a clever idea, using a data: URI as a null, which we could have used in some other situations. But "data:" is not a valid URI, the syntax shows that it must be "data:,". 3. Since draft-schulzrinne-dispatch-callinfo-spam specifies a manner of indicating characteristics of a call, it comes to mind that the "type" category could be signaled using a new series of "alert" URNs: urn:alert:type:business urn:alert:type:debt-collection etc. But it's hard to place that URN well. It seems to be the correct choice to put the spam information in a Call-Info header, but an "alert" URN won't affect alerting unless it's placed in an Alert-Info header. Dale From nobody Tue Oct 4 12:54:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE5129469 for ; Tue, 4 Oct 2016 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 C7NGm-z3cEeX for ; Tue, 4 Oct 2016 12:54:07 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E730129467 for ; Tue, 4 Oct 2016 12:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z3RifF9/pY9VjojfobGM+LCw01e9gwrnLAJelHHbOtc=; b=JqFy9aqTCJHcTawna4HK0K9UQao14YLNIR1AurOLw6seirmAbOJK79MmdCx5spHrmo67G703My1Q6xcIim61uqfJlb3DccxecU+D/LU6LnatEpoGsQW5HdFC0+DrlEx6MrRXVTYU8HynNEDDPr91oyMfkMS2abWX/+vASjY6BLs= From: Henning Schulzrinne To: "Dale R. Worley" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSHmlpjqIJi1PJIEa3EccQvSjRiaCYs80v Date: Tue, 4 Oct 2016 19:54:02 +0000 Message-ID: References: (Henning.Schulzrinne@fcc.gov),<87pongvvs3.fsf@hobgoblin.ariadne.com> In-Reply-To: <87pongvvs3.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 2b2343cb-cc69-4cbe-1c29-08d3ec9030db x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 6:Iaknd8g0WtDmdc/OJD6d0KEkHGUY5JxcXyKXeTuhLLQUZf8PV5CykndF64sJcqdkM6uYNVpy7GbAM5cfLl4hc8ezrPGBBak03O2oUFBREg7JXEs7h7d+ac27YRUYIvIbuxrpNfKNDaB90txbkm33DDBh4JsAlSfZ9HUSZ6Wi5HiUei0Zp2HLrH+jUd3Nieb1lUD6grJDgcvbXGEUre96rAAFwBP1WPZ7HOM4whWCV/Fo9sTnTyGFrW7xL2fP7XVnfDzDkiRGSZAOdg1wxLnYoNcgCSDtLNeujhljBsf7tNTwRg9Fit9JP4nDPkO4yl3b; 5:pNkxhRJQflgAVM3a0UtXB/US7383y0ZutooEs3k9Bwk7o1He5QcXyKkl06eDXL19oFpPkxM7KqT5P8qlnkDlF+2ngOGOz8NByGXOoUJefuabFOTkSDmVEB0fNJQEqqRWwr9EOyk0GIKn65ohZkoPy/pXA5BrA93IwT8OowvfWzc=; 24:FgCnAWayd30em9O9ZGS4dail/Oys/GJkiHv1L2G25e3uIAC5Ma7MBb7i9quTE3ej96Czmk2EoFu9KT3JDUVzehz/KLWOWJt3mUmuOkT4kpg=; 7:pr6SSzGPo1K/jVKHpEoAaVc4zI8OPiWc5j5DyZo8pUeymvbrYo7Kseoa3bPC5mIx4bqZW5lllNqVcMHUYtNE0Xvd5HEm+odzKKo8Prip+U7MY12iTpmNoveNr46wb63k6B0UYpkzpbwYQaRNjeNz2Ks7fRAqkYt54YU7C4XGRKys1mCxetPs3kP9q+UXWTHQyLj7NDXbzgd0eUqv3wxbhAPG0FA1zTDKldrMqZkneFy8ZKEz2l/YeIAV+0AffLbjqzcKXTAKa6Rn0fJsRl7PQ40T7UvHJaRrGo3o1Fhfii/3fodNB475P4kR6sXcznlwR++5roFi1eDgbRSXqvMqig== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 00851CA28B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(54356999)(6916009)(7906003)(101416001)(74316002)(2950100002)(106356001)(7846002)(19617315012)(10400500002)(76176999)(50986999)(7736002)(8936002)(76576001)(19580405001)(19580395003)(99286002)(106116001)(33656002)(66066001)(122556002)(105586002)(9686002)(81166006)(8676002)(77096005)(110136003)(15975445007)(68736007)(81156014)(19625215002)(2900100001)(7696004)(16236675004)(4326007)(97736004)(3660700001)(5660300001)(92566002)(189998001)(86362001)(5002640100001)(87936001)(102836003)(6116002)(586003)(3846002)(11100500001)(3280700002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634190481CC0226A5951669EAC50CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2016 19:54:02.7262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 19:54:09 -0000 --_000_CY1PR09MB0634190481CC0226A5951669EAC50CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dale, thanks for your comments. In this particular case, I disagree with your fir= st argument. The whole point of the "Unwanted" response is exactly that the= UAC is making a decision on behalf of the destination number and all assoc= iated destinations (UACs). It does want any forking to stop immediately. It= never wants to hear from the number again, on any device associated with t= he destination number. This is meant for single-person/household/office tel= URIs as the common use case, but maybe there are cases (some kind of group= destination?) we need to carve out where this should not be used. A 4xx does not seem to have the intended effect. "Unwanted here" is also am= biguous - what is the serving carrier supposed to do with that? "Hey guys, = make up your minds - do you want this caller or not?" Henning ________________________________ From: Dale R. Worley Sent: Tuesday, October 4, 2016 2:01:00 PM To: Henning Schulzrinne Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts Henning Schulzrinne writes: > https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwant= ed/ > > https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam= / 1. I like the symbolism of using 666 as a response code, but 6xx codes are generally a bad idea because they require one UAC to assert a fact about all the other possible destinations of the INVITE, which the UAC cannot know. (See draft-worley-6xx-considered-harmful.) So it should be a 4xx response code. 2. draft-schulzrinne-dispatch-callinfo-spam says: If the entity inserting the header field does not have information it wants to link to, it MUST use an empty data URL [RFC2397] as a placeholder, as in "data:". (The Call-Info header field syntax makes the URI itself mandatory.) That's a clever idea, using a data: URI as a null, which we could have used in some other situations. But "data:" is not a valid URI, the syntax shows that it must be "data:,". 3. Since draft-schulzrinne-dispatch-callinfo-spam specifies a manner of indicating characteristics of a call, it comes to mind that the "type" category could be signaled using a new series of "alert" URNs: urn:alert:type:business urn:alert:type:debt-collection etc. But it's hard to place that URN well. It seems to be the correct choice to put the spam information in a Call-Info header, but an "alert" URN won't affect alerting unless it's placed in an Alert-Info header. Dale --_000_CY1PR09MB0634190481CC0226A5951669EAC50CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dale,


thanks for your comments. In this particular case, I disagree with your = first argument. The whole point of the "Unwanted" response is exa= ctly that the UAC is making a decision on behalf of the destination number = and all associated destinations (UACs). It does want any forking to stop immediately. It never wants to hear from the= number again, on any device associated with the destination number. This i= s meant for single-person/household/office tel URIs as the common use case,= but maybe there are cases (some kind of group destination?) we need to carve out where this should not be = used.


A 4xx does not seem to have the intended effect. "Unwanted here&quo= t; is also ambiguous - what is the serving carrier supposed to do with that= ? "Hey guys, make up your minds - do you want this caller or not?"= ;


Henning

From: Dale R. Worley <= worley@ariadne.com>
Sent: Tuesday, October 4, 2016 2:01:00 PM
To: Henning Schulzrinne
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts
 
Henning Schulzrinne <Henning.Schulzrinne@fcc.go= v> writes:
> https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted= /
>
> https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/<= /a>

1. I like the symbolism of using 666 as a response code, but 6xx codes
are generally a bad idea because they require one UAC to assert a fact
about all the other possible destinations of the INVITE, which the UAC
cannot know.  (See draft-worley-6xx-considered-harmful.)  So it s= hould
be a 4xx response code.

2. draft-schulzrinne-dispatch-callinfo-spam says:

   If the entity
   inserting the header field does not have information it wants = to link
   to, it MUST use an empty data URL [RFC2397] as a placeholder, = as in
   "data:".  (The Call-Info header field syntax ma= kes the URI itself
   mandatory.)

That's a clever idea, using a data: URI as a null, which we could have
used in some other situations.  But "data:" is not a valid U= RI, the
syntax shows that it must be "data:,".

3. Since draft-schulzrinne-dispatch-callinfo-spam specifies a manner of
indicating characteristics of a call, it comes to mind that the "type&= quot;
category could be signaled using a new series of "alert" URNs:
    urn:alert:type:business
    urn:alert:type:debt-collection
    etc.

But it's hard to place that URN well.  It seems to be the correct choi= ce
to put the spam information in a Call-Info header, but an "alert"= URN
won't affect alerting unless it's placed in an Alert-Info header.

Dale

 --_000_CY1PR09MB0634190481CC0226A5951669EAC50CY1PR09MB0634namp_-- From nobody Thu Oct 6 04:25:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AFC12950F for ; Thu, 6 Oct 2016 04:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 Thld_e42W5Lr for ; Thu, 6 Oct 2016 04:25:46 -0700 (PDT) Received: from forward12o.cmail.yandex.net (forward12o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::1e2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE48129602 for ; Thu, 6 Oct 2016 04:25:43 -0700 (PDT) Received: from mxback1g.mail.yandex.net (mxback1g.mail.yandex.net [77.88.29.162]) by forward12o.cmail.yandex.net (Yandex) with ESMTP id 8201021535; Thu, 6 Oct 2016 14:25:41 +0300 (MSK) Received: from web24g.yandex.ru (web24g.yandex.ru [95.108.253.233]) by mxback1g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id WqLIEDUS0K-PfxKImgt; Thu, 06 Oct 2016 14:25:41 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1475753141; bh=8ue/E9rN0S6ap4TfcBrg+eDVjKgT3CjOqeCK7fqRI5g=; h=From:To:Cc:Subject:Message-Id:Date; b=bFS0lS8yYoki+Ui7G3Ch0ggxxkpq7idT8ckI1pJcOI7e65yzKD8OucEFY0i93mrYu sw0ERSSzE7YB+sDyRDuJBsi3dvYZW3EBLw67JJahitjOxpmsN8xx0aWYM0vSAFx4+I HrHju3G/0HDSlCaEjift0MaFezOXrQN6wUxgnkFc= Authentication-Results: mxback1g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web24g.yandex.ru with HTTP; Thu, 06 Oct 2016 14:25:41 +0300 From: Anton Tveretin To: Henning Schulzrinne , Dale R. Worley MIME-Version: 1.0 Message-Id: <4291475753141@web24g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 06 Oct 2016 16:25:41 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Cc: DISPATCH list Subject: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 11:25:49 -0000 Hello Dale, Henning, and all, First, I do not agree with draft-worley-6xx-considered-harmful approach. I think that callee should be able to report either "fail this call", or "deflect this call to... with reason given", or "Fail, but I don't care if the call is deflected". To indicate "rejected by user", we have 603. 3GPP defines 403 as equivalent to 603; not in RFCs. RFC 3261 has a good example of this. But "spam" means something more than just an undesired call; it suggests that other users would consider the same call undesired. Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So, we still need a 4xx code. In practice, it seems that 5xx codes are not used, see the example above (Decline), where the condition is clearly UAS-side. Regards, Anton. From nobody Thu Oct 6 05:45:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C051295E7 for ; Thu, 6 Oct 2016 05:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 tEnI6yCtIjMq for ; Thu, 6 Oct 2016 05:45:13 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2107127A90 for ; Thu, 6 Oct 2016 05:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xI0zh6hHMHS1YjZQCFkZo2ZYboSMjKcWP0HJHEmUKhQ=; b=gAjIsHV/W494K2u9/3tExt8L7Hb4fp9r7PI4DXxhYXZxogAmPNblqPAc0NIytUqULNj+cqWkML6yKJ+qDT3C8WfbnJgxQAi6Fle4J0iMVreUMZJL0RJLgvogPGrwhmijr/TY2eJN6u6kxYmLR2/lHs9TZtUsHkwXbBlPHbYsikQ= From: Henning Schulzrinne To: Anton Tveretin Thread-Topic: 4xx vs 6xx (was Re: Two new VoIP spam drafts) Thread-Index: AQHSH8RkUGymfmKcfEurqeiaCjjufKCbXw+h Date: Thu, 6 Oct 2016 12:45:07 +0000 Message-ID: References: <4291475753141@web24g.yandex.ru> In-Reply-To: <4291475753141@web24g.yandex.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 5643711f-fb12-42b3-21e4-08d3ede69aa1 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:WuvpInJvLnwkMSkzV4MKIeB3VY8c5ti4OuEAmAilck+q84OkRFlKoQ0pgahEFEsBXsi0V9wXYNa0bLWe+9lab3FqDDiwinz9AoSf/RMskPOcYeVqlarlYRWVLlZcM2/Y6TdE1zER22/o24ZwYQOqvzYprobCLbcnkPni0lKmdBW520Ldo0DfawHA2FsKbVh540qn9pcrHkbTlJgpUd1ujJZTvx3r4QzepqMABp+Ovfczk7TZHHbQgd3XqKnkGE/70OpaEUsUu1BMLC/txFcxtEFmfKPY8e8nRKD4C9dhccfOumOUUsnm3DqhYaa7slTa; 5:Kx4syJZdouM+/AocKbZ3mzrP0utA05ixKrhtGVQNnI8mlljsV8EFn13ETkdKhOx6XI8pr54O/IE4P0qs+FoUfSchUJqGZ2ZvMENI2hEzTD1nv9szjXEDtSq5S8Nz94NC4WRpJjJNwyiVynA/euK1QQIkndNPOrllGkbFjzB4qkY=; 24:6Vnil6gQa5nlJVdPb1WHjR6EiCoY1juwWUXIj8wUyFRLOwYq6M1YGl9/MlMdII50rdifEraFvp1AnFNTCmNaq+6A4kwAJQX9iXQZVmiEGAk=; 7:prMI17zLUn65dactlMKdYuIoykQgZaTJR85Ay2++pktwqspHJX3U4DDUWHpg/QjXb++js/762BeJe9t6pHmrNLd6G0cYcOTZb4+t9UNSsN4tR1jKr1Tk1iS/ljc0Qm/TsLmf8b+NiyUmAMCnSOuZVhJsaGtRIyUVKjcgaP7fFvCEj+VxFoVn9OudGDxzt0cG7VER2BE1G9ZbZkMEXR9mx38DWY3fOOnr/4xEo5laZMcJyrhga+4Sn9HymWWAedFph6JWNyfmIyUM01UWmlcopYl1T/wNdFoMbQw7Oi5jJNu4YxqPfMwCDlCVaha2QN1RATkmQUHmvcQPu5AZ6KtYMA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(144735808701293); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(51444003)(106356001)(4326007)(99286002)(81156014)(68736007)(101416001)(3660700001)(8676002)(106116001)(105586002)(81166006)(7736002)(7846002)(87936001)(86362001)(76576001)(2906002)(3846002)(19627405001)(586003)(6116002)(102836003)(2950100002)(92566002)(66066001)(6606003)(2900100001)(19580405001)(19580395003)(77096005)(7696004)(11100500001)(110136003)(10400500002)(8936002)(3280700002)(6916009)(97736004)(3900700001)(16236675004)(189998001)(54356999)(50986999)(74316002)(33656002)(19625215002)(5002640100001)(5660300001)(9686002)(76176999)(122556002)(23180200002)(563744003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E06EF6B4630328E82C86EAC70CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 12:45:08.0052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 12:45:18 -0000 --_000_CY1PR09MB0634E06EF6B4630328E82C86EAC70CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see the Reason restriction you mention. Indeed, RFC 3326 has an exa= mple that seems to contradict that contention: Reason: SIP ;cause=3D600 ;text=3D"Busy Everywhere" Henning ________________________________ From: Anton Tveretin Sent: Thursday, October 6, 2016 7:25 AM To: Henning Schulzrinne; Dale R.Worley Cc: DISPATCH list Subject: 4xx vs 6xx (was Re: Two new VoIP spam drafts) Hello Dale, Henning, and all, First, I do not agree with draft-worley-6xx-considered-harmful approach. I = think that callee should be able to report either "fail this call", or "def= lect this call to... with reason given", or "Fail, but I don't care if the = call is deflected". To indicate "rejected by user", we have 603. 3GPP defin= es 403 as equivalent to 603; not in RFCs. RFC 3261 has a good example of th= is. But "spam" means something more than just an undesired call; it suggests th= at other users would consider the same call undesired. Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So,= we still need a 4xx code. In practice, it seems that 5xx codes are not use= d, see the example above (Decline), where the condition is clearly UAS-side= . Regards, Anton. --_000_CY1PR09MB0634E06EF6B4630328E82C86EAC70CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don't see the Reason restriction you mention. Indeed, RFC 3326 has an = example that seems to contradict that contention:


Reason: SIP ;cause=3D600 ;text=3D"=
;Busy Everywhere"

Henning

From: Anton Tveretin <= tveretinas@yandex.ru>
Sent: Thursday, October 6, 2016 7:25 AM
To: Henning Schulzrinne; Dale R.Worley
Cc: DISPATCH list
Subject: 4xx vs 6xx (was Re: Two new VoIP spam drafts)
 
Hello Dale, Henning, and all,
First, I do not agree with draft-worley-6xx-considered-harmful approach. I = think that callee should be able to report either "fail this call"= ;, or "deflect this call to... with reason given", or "Fail,= but I don't care if the call is deflected". To indicate "rejected by user", we have 603. 3GPP defines 403 as equivalent = to 603; not in RFCs. RFC 3261 has a good example of this.
But "spam" means something more than just an undesired call; it s= uggests that other users would consider the same call undesired.
Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So,= we still need a 4xx code. In practice, it seems that 5xx codes are not use= d, see the example above (Decline), where the condition is clearly UAS-side= .
Regards,
Anton.

--_000_CY1PR09MB0634E06EF6B4630328E82C86EAC70CY1PR09MB0634namp_-- From nobody Thu Oct 6 05:55:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1180512955E for ; Thu, 6 Oct 2016 05:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 LWZrOhMdO4sb for ; Thu, 6 Oct 2016 05:55:46 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 0D80612963C for ; Thu, 6 Oct 2016 05:55:46 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id b75so15141489lfg.3 for ; Thu, 06 Oct 2016 05:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=oDEka0MS9KTSgKRT6UC5WkdOn2lCu2dQ0RxbbVUz2fA=; b=RwBmrH8ev6SMvw3vJq/KYgz+b0FxzXqGS9YDiuwvdtLjsMOCpZtAjDXEY/YFh2Pkr2 SV2qH3j8519ugrDjjbNBSY0PofTWesBKCbv2cUrmTwG8+4SQRPJWzZu6TU1T2Lm+fj6F Z+7nS/Ut6Q/rZ/3qPdOMt6UlBArftYSr2O/bQvELTKuvcvKME7r4AMLETJ6cdr8/2TeM iaqIcJPjw9Xm4N+inpOqTj7aYjSR9Egf00LiJ3rGyP1uoav5Oavml64HiwGPqNAgSNtF jw7Pj09Coi5ztU+GGHPQ7OiNRurRCDD+WEahOBVWsHVCeSrRcX2pEieUif/zT2/6ZYrh xvxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=oDEka0MS9KTSgKRT6UC5WkdOn2lCu2dQ0RxbbVUz2fA=; b=Tc2qm33RFBy9HCB8nL5DT/ex0utvkoUD6SrvK+HFKIwhwgg7RXqxg3tRMFtKMAazxG KGf2ejq3vxCIE4FJ6aoOyPEsB1Ot4MOb4kp0ojbWe40JmRroVBGjVr/97hhsCxi3eLSy hT5DR/IcFwawX9YEPcTXsuhmkIIq8nZoGwMKfMu6TnVTMuuZVfiVlUX1hUjLmgher+0f kyBjUw9es7t4Povk1GSNPQFDMzVSV786pqrdSI/PuE1qS18hsoi/osetlg/l0cDzLc7h MbiFNviv+nwxGb/nqaEv83lOAcH8ETNSb3aoi72F50WTN6hUv1+NAetySsTOsg9t7xa3 cYtA== X-Gm-Message-State: AA6/9RnkQK/XWgFx8/7whv1XJsL56MyORrIqO8BRH82KC2DHOu+KcnpV0aJIasS4JO6QvDVAsGSs/3BL6+zqaAqW X-Received: by 10.25.89.16 with SMTP id n16mr6504580lfb.68.1475758543904; Thu, 06 Oct 2016 05:55:43 -0700 (PDT) From: Brett Tate References: <4291475753141@web24g.yandex.ru> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH29KwGNSQUQprL/M+jIJm3VtxnDQKpsmRSoDxqcaA= Date: Thu, 6 Oct 2016 08:55:42 -0400 Message-ID: <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> To: Henning Schulzrinne , Anton Tveretin , DISPATCH list Content-Type: multipart/alternative; boundary=001a11412d78c8b6b7053e31cf8b Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 12:55:51 -0000 --001a11412d78c8b6b7053e31cf8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RFC 3326 section 2 also indicates =E2=80=9CAny SIP status code MAY appear i= n the Reason header field of a request=E2=80=9D. *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Henning Schulzrinne *Sent:* Thursday, October 06, 2016 8:45 AM *To:* Anton Tveretin *Cc:* DISPATCH list *Subject:* Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) I don't see the Reason restriction you mention. Indeed, RFC 3326 has an example that seems to contradict that contention: Reason: SIP ;cause=3D600 ;text=3D"Busy Everywhere" Henning ------------------------------ *From:* Anton Tveretin *Sent:* Thursday, October 6, 2016 7:25 AM *To:* Henning Schulzrinne; Dale R.Worley *Cc:* DISPATCH list *Subject:* 4xx vs 6xx (was Re: Two new VoIP spam drafts) Hello Dale, Henning, and all, First, I do not agree with draft-worley-6xx-considered-harmful approach. I think that callee should be able to report either "fail this call", or "deflect this call to... with reason given", or "Fail, but I don't care if the call is deflected". To indicate "rejected by user", we have 603. 3GPP defines 403 as equivalent to 603; not in RFCs. RFC 3261 has a good example of this. But "spam" means something more than just an undesired call; it suggests that other users would consider the same call undesired. Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So, we still need a 4xx code. In practice, it seems that 5xx codes are not used, see the example above (Decline), where the condition is clearly UAS-side. Regards, Anton. --001a11412d78c8b6b7053e31cf8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

RF= C 3326 section 2 also indicates =E2=80=9CAny SIP status code MAY appear in = the Reason header field of a request=E2=80=9D.

=C2=A0

=C2=A0

I don't see the Reason restriction you = mention. Indeed, RFC 3326 has an example that seems to contradict that cont= ention:

=C2=A0

Reason: SIP ;cause=3D600 ;text=3D"Bus=
y Everywhere"

=C2=A0=

Henning

=

From: Anton Tveretin <tveretinas@yandex.ru>
Sent= : Thursday, October 6, 2016 7:25 AM
To: Henning Schulzrinne; = Dale R.Worley
Cc: DISPATCH list
Subject: 4xx vs 6xx (wa= s Re: Two new VoIP spam drafts)

=C2=A0

Hello Dale, = Henning, and all,
First, I do not agree with draft-worley-6xx-considered= -harmful approach. I think that callee should be able to report either &quo= t;fail this call", or "deflect this call to... with reason given&= quot;, or "Fail, but I don't care if the call is deflected". = To indicate "rejected by user", we have 603. 3GPP defines 403 as = equivalent to 603; not in RFCs. RFC 3261 has a good example of this.
But= "spam" means something more than just an undesired call; it sugg= ests that other users would consider the same call undesired.
Second, II= RC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So, we still = need a 4xx code. In practice, it seems that 5xx codes are not used, see the= example above (Decline), where the condition is clearly UAS-side.
Regar= ds,
Anton.

--001a11412d78c8b6b7053e31cf8b-- From nobody Thu Oct 6 10:48:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6C012974F for ; Thu, 6 Oct 2016 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 ydt_llwhGNnE for ; Thu, 6 Oct 2016 10:48:12 -0700 (PDT) Received: from email1.corp.yaanatech.com (12-229-59-67-static.dzbja.com [12.229.59.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D36812974D for ; Thu, 6 Oct 2016 10:48:12 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 6 Oct 2016 10:48:12 -0700 From: Michael Hammer To: "brett@broadsoft.com" , "Henning.Schulzrinne@fcc.gov" , "tveretinas@yandex.ru" , "dispatch@ietf.org" Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) Thread-Index: AQHSH8+FiQh/nbOOFU+IFD5ErfH/bqCb150A///bkOA= Date: Thu, 6 Oct 2016 17:48:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> In-Reply-To: <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.13] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02EA_01D21FD8.462EB9B0" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 17:48:14 -0000 ------=_NextPart_000_02EA_01D21FD8.462EB9B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02EB_01D21FD8.462EB9B0" ------=_NextPart_001_02EB_01D21FD8.462EB9B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like the idea of a unique non-overloaded code point that=20 can be used to drive some peg-counts or big data analysis of calls=20 to highlight the numbers and rates in real-time, so that=20 systems could proactively tag next calls to say to called user=20 that this next call had 100,000 users saying it was a robo-call. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com =20 +1 408 202 9291 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system. =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Brett = Tate Sent: Thursday, October 06, 2016 8:56 AM To: Henning Schulzrinne ; Anton Tveretin = ; DISPATCH list Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) =20 RFC 3326 section 2 also indicates =E2=80=9CAny SIP status code MAY = appear in the Reason header field of a request=E2=80=9D. =20 From: dispatch [mailto:dispatch-bounces@ietf.org = ] On Behalf Of Henning Schulzrinne Sent: Thursday, October 06, 2016 8:45 AM To: Anton Tveretin Cc: DISPATCH list Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) =20 I don't see the Reason restriction you mention. Indeed, RFC 3326 has an = example that seems to contradict that contention: =20 Reason: SIP ;cause=3D600 ;text=3D"Busy Everywhere" =20 Henning _____ =20 From: Anton Tveretin = > Sent: Thursday, October 6, 2016 7:25 AM To: Henning Schulzrinne; Dale R.Worley Cc: DISPATCH list Subject: 4xx vs 6xx (was Re: Two new VoIP spam drafts)=20 =20 Hello Dale, Henning, and all, First, I do not agree with draft-worley-6xx-considered-harmful approach. = I think that callee should be able to report either "fail this call", or = "deflect this call to... with reason given", or "Fail, but I don't care = if the call is deflected". To indicate "rejected by user", we have 603. = 3GPP defines 403 as equivalent to 603; not in RFCs. RFC 3261 has a good = example of this. But "spam" means something more than just an undesired call; it suggests = that other users would consider the same call undesired. Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. = So, we still need a 4xx code. In practice, it seems that 5xx codes are = not used, see the example above (Decline), where the condition is = clearly UAS-side. Regards, Anton. ------=_NextPart_001_02EB_01D21FD8.462EB9B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I like the idea of a unique non-overloaded code point that =

can be used to drive some peg-counts or big data analysis of calls =

to highlight the numbers and rates in real-time, so that =

systems could proactively tag next calls to say to called user =

that this next call had 100,000 users saying it was a = robo-call.

 

________________________________= <= o:p>

Michael Hammer<= o:p>

michael.hammer@yaanatech.com= <= o:p>

+1 408 202 9291<= o:p>

=C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you = have received this message in error, please notify us and remove it from = your system.<= o:p>

 

From:<= /b> = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Brett = Tate
Sent: Thursday, October 06, 2016 8:56 AM
To: = Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; Anton Tveretin = <tveretinas@yandex.ru>; DISPATCH list = <dispatch@ietf.org>
Subject: Re: [dispatch] 4xx vs 6xx = (was Re: Two new VoIP spam drafts)

 

RFC 3326 section 2 also indicates =E2=80=9CAny SIP status code MAY = appear in the Reason header field of a = request=E2=80=9D.

 

From: = dispatch [mailto:dispatch-bounces@ietf.org] = On Behalf Of Henning Schulzrinne
Sent: Thursday, = October 06, 2016 8:45 AM
To: Anton Tveretin
Cc: = DISPATCH list
Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two = new VoIP spam drafts)

 

I don't see the = Reason restriction you mention. Indeed, RFC 3326 has an example that = seems to contradict that contention:

 = 

Reason: SIP ;cause=3D600 ;text=3D"Busy =
Everywhere"

 =

Henning

F= rom: = Anton Tveretin <tveretinas@yandex.ru>
S= ent: Thursday, October 6, 2016 7:25 AM
To: Henning = Schulzrinne; Dale R.Worley
Cc: DISPATCH = list
Subject: 4xx vs 6xx (was Re: Two new VoIP spam = drafts) =

 =

H= ello Dale, Henning, and all,
First, I do not agree with = draft-worley-6xx-considered-harmful approach. I think that callee should = be able to report either "fail this call", or "deflect = this call to... with reason given", or "Fail, but I don't care = if the call is deflected". To indicate "rejected by = user", we have 603. 3GPP defines 403 as equivalent to 603; not in = RFCs. RFC 3261 has a good example of this.
But "spam" means = something more than just an undesired call; it suggests that other users = would consider the same call undesired.
Second, IIRC 6xx codes are = not valid for Reason:; only 4xx and 5xx are. So, we still need a 4xx = code. In practice, it seems that 5xx codes are not used, see the example = above (Decline), where the condition is clearly = UAS-side.
Regards,
Anton.

------=_NextPart_001_02EB_01D21FD8.462EB9B0-- ------=_NextPart_000_02EA_01D21FD8.462EB9B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhBMAzfzqk7mKu8vbItErxUIMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDIyOTAwMDAwMFoXDTE4MDIyODIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWEk4s5ORfNfQ/oXDD k4mHDQDDpO3s2oEy7055JdLoleNQXEJGsv8EsqPagYul55uVZ57tmx2H1LjM6QfD7N821joisKa4 +l92JImsffrTnll8gxJ9VV9/WmGpPWwFg4ipw3qRdDhQJnQiNKzlqPMSIDE76uhrKv3hYE30tVIO R8U9erAprCBoHd2Ch1+pIGlFjl91//BR1sehnJR9Z1gZHMEqjto/jYPR1uEapueR6W+YuL9O9HmW RLA925xiZmzwKqB8HS0wG+PjLnMRnohdIh4e+/FKWksC82rP7vmP3SHOzQKdgdapaavCTx/1ZYiR N6cMT95ZCgB1aHXR1lCfAgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBX iSRv04vVx/Y5lWWITUJhWXUTnhM70UUqIEinNF+cV9+zY0lomYqoB8ovCfWrvx232tzX86NtreSn 9UjhBRj61oqSyK9v6P14dunX1MjRZmOVeKws3+XDS3NPsopui5YOPjSy02qhyVN4tIDCokj71db1 wO7uZ/DehNWkwFUgMKdVKM5LAGIDHgWn2dvzGi+ipdDNjMD2SxMnCSOiZ3z9gh/Yy+flNaXn5vLL O0AJEW5xCl2tbuPh/DghqlaiVeCLaCar3cj2Ka6ew5wRhNpvmno47b0C5w6JDxx++ijXjGPzYr57 J8QvCDs9f3Cn5doEF3bTQmcab+s3VEgIhAt1MYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDA2MTc0ODA5WjAjBgkqhkiG 9w0BCQQxFgQU1bEQDscNsNFRPxIO8X2BtJtpLHAwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQTAM386pO5irvL2yLRK8VCDCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwDQYJKoZIhvcNAQEBBQAEggEA T94Y4Zr9K5e2HOpKPwE12ooSLGlfE2ZwTbxBjrXTwcNAtEYc6c0QWGX1yWcqHmJisDdgjLmPwjuS OXv/4taPVu87zKqY0cT0SMmH8zeK2mEpDOROmvZF7GzmbaHeP3Ff5pTq4BPTH/qabiwGZtpOpIT4 vZjT6CtSMJ5ZOjc4XeoUclMEqrbPLUBP4TUNAuYahggpJqWclaqZZyTgITm2P/iSqWjk1rmtdXwS lNscT6ubFfr9Frn5QRy70yeliRDSLYOx1myr0qEecOPOjLNGLKbls++Xc2rs9FkNKnu6YXTDKwgt v2bWvyLJPIiR1GOf3iDOhK6RDwGgoFw313U7eAAAAAAAAA== ------=_NextPart_000_02EA_01D21FD8.462EB9B0-- From nobody Thu Oct 6 11:33:45 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9EF12975E for ; Thu, 6 Oct 2016 11:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ZmlDlSR4Ut3b for ; Thu, 6 Oct 2016 11:33:35 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4AF12973F for ; Thu, 6 Oct 2016 11:33:34 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-10v.sys.comcast.net with SMTP id sDT4b1a7XHqolsDU5bJrB1; Thu, 06 Oct 2016 18:33:33 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-04v.sys.comcast.net with SMTP id sDU4bb7h6VeHNsDU4bl8T9; Thu, 06 Oct 2016 18:33:33 +0000 To: dispatch@ietf.org References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> From: Paul Kyzivat Message-ID: <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> Date: Thu, 6 Oct 2016 14:33:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNB82zfw5xbfnWHNX2eiE5qImzO+imIEYuNY05EdjK1LtVBG5plEZDoD3xH1ub/+I7RGn6MREsEm/peSoYhn1haasgZ5urpferN/ODQazizkRfrWxRa3 F+/GWaniep9oQkcRxuw5m70lPErwnIcSh6UL43hWvmPjvKmMPxaN5YwzFpOzvbXs63CL9qpoGbV9ZA== Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:33:36 -0000 On 10/6/16 1:48 PM, Michael Hammer wrote: > I like the idea of a unique non-overloaded code point that > > can be used to drive some peg-counts or big data analysis of calls > > to highlight the numbers and rates in real-time, so that > > systems could proactively tag next calls to say to called user > > that this next call had 100,000 users saying it was a robo-call. This would be nice. But it depends on more than a unique response code. It also needs for users to only use that code for the semantic you want to tag it with. This depends as much on the UI provided to users as it does on the existence of the code(s). Of necessity the UI will be simple, with few choices for how to reject a call. (I guess one or possibly two.) Those can then be mapped to particular response codes. But it will be hard to get users to use those buttons for precisely the semantics we want to ascribe to the codes. (Do we we want the button to mean "unwanted robo-call", "call from undesired caller", "objectionable call content", or what?) Even though the IETF doesn't "do" UIs, it might be better to discuss the likely UI before fully defining the code(s). Thanks, Paul From nobody Thu Oct 6 11:46:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA92A12943D for ; Thu, 6 Oct 2016 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 77LSlOetm8so for ; Thu, 6 Oct 2016 11:46:35 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5741293E9 for ; Thu, 6 Oct 2016 11:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0VMODiND8WXrYlol/5agPrFbiVpq/D4qhyoBAf1Bsvo=; b=mn1PKgHuhroqjy1IP7HhwwTCbEkYzZ0k3xXyi+ZMcUnj+klJbRx+synUztvLoVYMhQ4s4fkesrp5fQpzsETxg3K+7diMbTYPMMnbB+OrIOS/KwLzNDV5sE8Jn3xQ0CbpBS8WZHhbAGiuJQJU3Kd62if405WMLdCT4Ggz/I5qSEc= From: Henning Schulzrinne To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) Thread-Index: AQHSH8RkUGymfmKcfEurqeiaCjjufKCbXw+hgAADTACAAFG4gIAADKsAgAAA5ao= Date: Thu, 6 Oct 2016 18:46:32 +0000 Message-ID: References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com>, <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> In-Reply-To: <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: ab2fc0b0-38cf-4fc0-690e-08d3ee191766 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:LLm3uG/wlHJp76w0KQ81Af+anGsfQ/orbO9+ppkTljWOCLi5bs/MWnG9l7MAXtXVwVxnz2bRKqVfYPDQvNPYVbwLdCimZp9KagQXQNN5WrOmRo8cXLji2xNI9nMT86+rVB92Filq4KZnBiJCq3u+BpcRvrZVcWdWdHV7/x/2WaQlgHq+CE1lTH5JxwTxEL00SWn9SKELfof/5Uo09RqqzesjeLG/0Ckb+XcKVQM62Ep/L2gsWRCj4Ds+hAIJV8W9ASA8fDM1C+5ozav1dnB5KV8VoPciHYe2EEPnuzoxuF4m1Gv/GpDsHJtxyzfi9Al3; 5:4UMAPvaaSAz2NaWgea9n1656RIlL/hLXirGgeDCyVAb0J+smOZ0zv914tpzIYbJlxr8E1HrfDeCZiw/qOWHYcJ/QSAMRH6vN6OPXl3WqzsLllKqbypoV6h5zJ4moNZxKitwdxvEugu15q1I2YjjjQ2Al30PpslC5PGzSqJWUyfo=; 24:RO5k2HKUym4HPpOLWvZzNobTN3UqDZEQR3knuxnBjA94Z2TWEluQFQSsjBk5lpPAPFSpzRhDvp2v3e5U7YmEkP4oGuNN+WhPPnRW44dJhJ0=; 7:wZK8/ZPTzaGEuB1e69fsQa1eP3OBIybvt6D82c9f4lfaEMFMRYTCMeJQ0GrGFvZfUsNBpNHCukmoK2MCqwPrVbdg5KAljuGvpwp8eltXIxLZ/xAhrTqSI2YCGlMjOSWwfIgQWPMKf62a3y6N9JQaOiCGQOkY4PQrzvXRPhPh7MDuazaYu5I319PvJ9XtmbnqkhA8/3HbDpkYffzofNHZXjeifVQ+23iWpWW2PVk3ZrSV38MhPu78ekRvHLWbkWOGIix30LSE62lWaSJK+LG2fM+lR4A0CaYiWMMvnrX1/HTR5R7ZhfX6I/9piuFUqKPCDZYwh5zjFXePhQfnnC/Z1Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(24454002)(106356001)(99286002)(81156014)(101416001)(68736007)(3660700001)(8676002)(106116001)(105586002)(81166006)(7736002)(7846002)(7906003)(87936001)(2171001)(76576001)(86362001)(2906002)(19627405001)(586003)(102836003)(6116002)(92566002)(2950100002)(77096005)(19580395003)(19580405001)(15975445007)(2900100001)(7696004)(11100500001)(10400500002)(3280700002)(8936002)(6606003)(2501003)(5001770100001)(97736004)(16236675004)(3900700001)(107886002)(189998001)(54356999)(5660300001)(74316002)(93886004)(50986999)(33656002)(19625215002)(19617315012)(5002640100001)(9686002)(122556002)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E96169AFB5CEC6EF8606EAC70CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 18:46:32.1180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 18:46:37 -0000 --_000_CY1PR09MB0634E96169AFB5CEC6EF8606EAC70CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Without getting into UI engineering, the email spam experience may be helpf= ul. From what I can tell, most email clients have a single "spam" button, w= ithout any categorization, and that seems to work reasonably well. It does = tend to conflate, for email, the reaction to offers by Nigerian princes wit= h email where the receiver does not remember that they signed up for (or ju= st fat-fingered). Since this is a statistical measure, a bit of noise seems= tolerable. ________________________________ From: dispatch on behalf of Paul Kyzivat Sent: Thursday, October 6, 2016 2:33 PM To: dispatch@ietf.org Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) On 10/6/16 1:48 PM, Michael Hammer wrote: > I like the idea of a unique non-overloaded code point that > > can be used to drive some peg-counts or big data analysis of calls > > to highlight the numbers and rates in real-time, so that > > systems could proactively tag next calls to say to called user > > that this next call had 100,000 users saying it was a robo-call. This would be nice. But it depends on more than a unique response code. It also needs for users to only use that code for the semantic you want to tag it with. This depends as much on the UI provided to users as it does on the existence of the code(s). Of necessity the UI will be simple, with few choices for how to reject a call. (I guess one or possibly two.) Those can then be mapped to particular response codes. But it will be hard to get users to use those buttons for precisely the semantics we want to ascribe to the codes. (Do we we want the button to mean "unwanted robo-call", "call from undesired caller", "objectionable call content", or what?) Even though the IETF doesn't "do" UIs, it might be better to discuss the likely UI before fully defining the code(s). Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CY1PR09MB0634E96169AFB5CEC6EF8606EAC70CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Without getting into UI engineering, the email spam experience may be he= lpful. From what I can tell, most email clients have a single "spam&qu= ot; button, without any categorization, and that seems to work reasonably w= ell. It does tend to conflate, for email, the reaction to offers by Nigerian princes with email where the recei= ver does not remember that they signed up for (or just fat-fingered). Since= this is a statistical measure, a bit of noise seems tolerable.


From: dispatch <dispat= ch-bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu= >
Sent: Thursday, October 6, 2016 2:33 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts= )
 
On 10/6/16 1:48 PM, Michael Hammer wrote:
> I like the idea of a unique non-overloaded code point that
>
> can be used to drive some peg-counts or big data analysis of calls
>
> to highlight the numbers and rates in real-time, so that
>
> systems could proactively tag next calls to say to called user
>
> that this next call had 100,000 users saying it was a robo-call.

This would be nice. But it depends on more than a unique response code. It also needs for users to only use that code for the semantic you want to tag it with. This depends as much on the UI provided to users as it
does on the existence of the code(s).

Of necessity the UI will be simple, with few choices for how to reject a call. (I guess one or possibly two.) Those can then be mapped to
particular response codes. But it will be hard to get users to use those buttons for precisely the semantics we want to ascribe to the codes. (Do we we want the button to mean "unwanted robo-call", "call fr= om undesired
caller", "objectionable call content", or what?)

Even though the IETF doesn't "do" UIs, it might be better to disc= uss the
likely UI before fully defining the code(s).

        Thanks,
        Paul

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_CY1PR09MB0634E96169AFB5CEC6EF8606EAC70CY1PR09MB0634namp_-- From nobody Thu Oct 6 13:21:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817E7129408 for ; Thu, 6 Oct 2016 13:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 9QRxJPhHQp7h for ; Thu, 6 Oct 2016 13:21:13 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2381293DF for ; Thu, 6 Oct 2016 13:21:12 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 5D13FA0CBA; Thu, 6 Oct 2016 22:21:11 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 3A1F81A0068; Thu, 6 Oct 2016 22:21:11 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Thu, 6 Oct 2016 22:21:10 +0200 From: To: Anton Tveretin , Henning Schulzrinne , Dale R.Worley Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) Thread-Index: AQHSH8RnI/HeD6aGeE2J9wWfaqqNJaCb3QlA Date: Thu, 6 Oct 2016 20:21:10 +0000 Message-ID: <3358_1475785271_57F6B237_3358_11690_1_8B970F90C584EA4E97D5BAAC9172DBB81AAE3AA8@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4291475753141@web24g.yandex.ru> In-Reply-To: <4291475753141@web24g.yandex.ru> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 20:21:14 -0000 Hello Anton, I would like to correct the fact that in 3GPP 403 is not equivalent to 603.= When you have a barring service, it is a 603 response that is sent to the = calling party and never a 403. The Reason header defines a protocol value and once you are using one proto= col value, you can use any value created by this protocol. In RFC3326 it is mentioned "SIP: The cause parameter contains a SIP status = code." BR, Marianne -----Message d'origine----- De=A0: dispatch [mailto:dispatch-bounces@ietf.org] De la part de Anton Tver= etin Envoy=E9=A0: jeudi 6 octobre 2016 13:26 =C0=A0: Henning Schulzrinne; Dale R.Worley Cc=A0: DISPATCH list Objet=A0: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) Hello Dale, Henning, and all, First, I do not agree with draft-worley-6xx-considered-harmful approach. I = think that callee should be able to report either "fail this call", or "def= lect this call to... with reason given", or "Fail, but I don't care if the = call is deflected". To indicate "rejected by user", we have 603. 3GPP defin= es 403 as equivalent to 603; not in RFCs. RFC 3261 has a good example of th= is. But "spam" means something more than just an undesired call; it suggests th= at other users would consider the same call undesired. Second, IIRC 6xx codes are not valid for Reason:; only 4xx and 5xx are. So,= we still need a 4xx code. In practice, it seems that 5xx codes are not use= d, see the example above (Decline), where the condition is clearly UAS-side. Regards, Anton. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Oct 7 07:18:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190AC129613 for ; Fri, 7 Oct 2016 07:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 gmJ6oCyfyVUF for ; Fri, 7 Oct 2016 07:18:16 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76625129610 for ; Fri, 7 Oct 2016 07:18:15 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-11v.sys.comcast.net with SMTP id sVxub5B4clSxssVyYbQSfa; Fri, 07 Oct 2016 14:18:14 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-ch2-15v.sys.comcast.net with SMTP id sVyXbN7tkMTfnsVyYbtGuZ; Fri, 07 Oct 2016 14:18:14 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u97EIDbp009518; Fri, 7 Oct 2016 10:18:13 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u97EICLU009515; Fri, 7 Oct 2016 10:18:12 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Henning Schulzrinne In-Reply-To: (Henning.Schulzrinne@fcc.gov) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 07 Oct 2016 10:18:12 -0400 Message-ID: <87y4205jkr.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMt7Tgj7tNVsWGZDsxUx4UdLge//1h7Ru+ladUxfzD/Hul6lR1o86gAW56er6TDo4brjUVDPHXBJsJHP0BiKs0aiB5ylfMYk8FDKtaNkrdiboo/MADb5 WWX7bnOkxRL8/JfkKL/4pnYSFNZy8VYoLmngiH/mZ8SWOhQP4Y6Fz/zQHfXARjgU1w5BDWdoRozUex7k+PdRpdX1GHIc8M+25vA= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 14:18:17 -0000 Henning Schulzrinne writes: > The whole point of the "Unwanted" response is > exactly that the UAC is making a decision on behalf of the destination > number and all associated destinations (UACs). OTOH, my point is that the 6xx response applies to all forks of the called number, which may not be the destination number. In fact, the called UA doesn't *know* the called number. > It does want any forking to stop immediately. It never wants to hear > from the number again, on any device associated with the destination > number. This is meant for single-person/household/office tel URIs as > the common use case, but maybe there are cases (some kind of group > destination?) we need to carve out where this should not be used. There are an infinite number of possibilities. I expect the commonest case is for all possible destinations of a call to be under control of one person or organization, but there's no requirement for that in SIP. Dale From nobody Fri Oct 7 08:33:06 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A05129679 for ; Fri, 7 Oct 2016 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 rbmYyo_1tWop for ; Fri, 7 Oct 2016 08:33:03 -0700 (PDT) Received: from email1.corp.yaanatech.com (12-229-59-67-static.dzbja.com [12.229.59.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2889C12967A for ; Fri, 7 Oct 2016 08:33:03 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 7 Oct 2016 08:33:02 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) Thread-Index: AQHSH8+FiQh/nbOOFU+IFD5ErfH/bqCb150A///bkOCAAILUAIAA6fKg Date: Fri, 7 Oct 2016 15:33:01 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BD03E98A@sc9-ex2k10mb1.corp.yaanatech.com> References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> In-Reply-To: <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C2_01D2208E.8F129410" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 15:33:05 -0000 ------=_NextPart_000_00C2_01D2208E.8F129410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, Understand. But, this is chicken or egg issue. An app developer can't do the UI without the protocol element to make it useful. Agree with thought that a single "spam" button may be enough of an indicator. Operator would have to decide at what statistical level to start tagging = new calls with "possible spam" label. ________________________________ Michael Hammer michael.hammer@yaanatech.com +1=A0408 202 9291 =A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you have received = this message in error, please notify us and remove it from your system. -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: Thursday, October 06, 2016 2:34 PM To: dispatch@ietf.org Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) On 10/6/16 1:48 PM, Michael Hammer wrote: > I like the idea of a unique non-overloaded code point that > > can be used to drive some peg-counts or big data analysis of calls > > to highlight the numbers and rates in real-time, so that > > systems could proactively tag next calls to say to called user > > that this next call had 100,000 users saying it was a robo-call. This would be nice. But it depends on more than a unique response code.=20 It also needs for users to only use that code for the semantic you want = to tag it with. This depends as much on the UI provided to users as it does = on the existence of the code(s). Of necessity the UI will be simple, with few choices for how to reject a call. (I guess one or possibly two.) Those can then be mapped to = particular response codes. But it will be hard to get users to use those buttons = for precisely the semantics we want to ascribe to the codes. (Do we we want = the button to mean "unwanted robo-call", "call from undesired caller", "objectionable call content", or what?) Even though the IETF doesn't "do" UIs, it might be better to discuss the likely UI before fully defining the code(s). Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_00C2_01D2208E.8F129410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhBMAzfzqk7mKu8vbItErxUIMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDIyOTAwMDAwMFoXDTE4MDIyODIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWEk4s5ORfNfQ/oXDD k4mHDQDDpO3s2oEy7055JdLoleNQXEJGsv8EsqPagYul55uVZ57tmx2H1LjM6QfD7N821joisKa4 +l92JImsffrTnll8gxJ9VV9/WmGpPWwFg4ipw3qRdDhQJnQiNKzlqPMSIDE76uhrKv3hYE30tVIO R8U9erAprCBoHd2Ch1+pIGlFjl91//BR1sehnJR9Z1gZHMEqjto/jYPR1uEapueR6W+YuL9O9HmW RLA925xiZmzwKqB8HS0wG+PjLnMRnohdIh4e+/FKWksC82rP7vmP3SHOzQKdgdapaavCTx/1ZYiR N6cMT95ZCgB1aHXR1lCfAgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBX iSRv04vVx/Y5lWWITUJhWXUTnhM70UUqIEinNF+cV9+zY0lomYqoB8ovCfWrvx232tzX86NtreSn 9UjhBRj61oqSyK9v6P14dunX1MjRZmOVeKws3+XDS3NPsopui5YOPjSy02qhyVN4tIDCokj71db1 wO7uZ/DehNWkwFUgMKdVKM5LAGIDHgWn2dvzGi+ipdDNjMD2SxMnCSOiZ3z9gh/Yy+flNaXn5vLL O0AJEW5xCl2tbuPh/DghqlaiVeCLaCar3cj2Ka6ew5wRhNpvmno47b0C5w6JDxx++ijXjGPzYr57 J8QvCDs9f3Cn5doEF3bTQmcab+s3VEgIhAt1MYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDA3MTUzMzAwWjAjBgkqhkiG 9w0BCQQxFgQUs04ZxoGvwxnpcfrVbE9bX71j9bowgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQTAM386pO5irvL2yLRK8VCDCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwDQYJKoZIhvcNAQEBBQAEggEA FkIORfhXpsPEDOxQw5n8KRPLJij9Kww/tNsGHr7f6o7PkQ6CbpOnLoXU7HKOc7CXoMPmVWpGTPY7 VgZcra+CcRcvf9oNMYe2vFPDbuE/8Gp8b2p8CmeoSXi6C9FPeoq0xOseMgz58D7nX9yS/rA+YQXd /M3M50toHE72AehYasa6pJNc1PwaoVJ+uIVTNF5sutJMsYWCgFBIuqvcvPQl09psf4QSihr2XWzt trCP62lrgAMdZkP/2He+d8QaqxmmLlP/DWZg30lUN0p91bLBcDI/yLg+21Gwc0njVaq8ORdf060N sMlk/iDIxLaHMHHNUS0nFdQcevzdox49yH4KXgAAAAAAAA== ------=_NextPart_000_00C2_01D2208E.8F129410-- From nobody Fri Oct 7 09:04:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E6D1295E2 for ; Fri, 7 Oct 2016 09:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hQsyVKMzXAVI for ; Fri, 7 Oct 2016 09:04:45 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 4A5B81295AD for ; Fri, 7 Oct 2016 09:04:45 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id j141so842269oih.0 for ; Fri, 07 Oct 2016 09:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=zu4UexDjOFgVUJaXbXc4r/csPx0O4969meKpiLQ4xYc=; b=CB6mK0q3WvwFmY91bfBgLspGWSu1gk222stlLVzYsF/FjH1bfiMSOPZKO6Gi5mRKQv odKOromXIQEFjMLzxg/cyIzVmyrJBKO1YyaN/pcu2sR/siQL5q20dHzXIO61YGvqKH78 ebErQGHg+lkx9CfVS8m3kKbWnkVViv2B9HPKRw08C7qMZP9rpnqzIMdYSpjttde0DW8K ZK0oVQFwTuYaZAVnHdahJh+U4jJiLmRbkJBSWb3R8yQbRdYvnBsByGd+Bpw/h6WjDLtN BjA7DtCzHD9k5mFu3hxQfGeQDPqlmeu9rbnVV+eP81pA8EJo1Nt8AtDJS6pIUQivINKx FdDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=zu4UexDjOFgVUJaXbXc4r/csPx0O4969meKpiLQ4xYc=; b=ihBMiB6qcgLxMxddRYK7OIX/6W9IOnwIefE8k03cZc1dGVFRDMjJW68F1ChNqmrzl/ 02X9uzck1e+PJ+DPzinCgA1pv3GUibq3A3mRCfFZAuycZzTr52c6ACBLde/1tIOLdPr/ 11f9ctN5NKSJ8nNoSQy50TbMgSyxxWuTZvk2SYdUXAfqrehcegdKzszWsxTXrb4UiMF5 sJS3PF1ViERnVgvJYVhkcd0y2wDqybQT6vVXmVYX5KnIQ0+bbw80k192Nzgg+VkTA/VK JGtI1GkE6RZGYBZTxnnt9lZwf1YxTZbkskfVr9BJRtgmUPVDxcNu8eVieF49i8jPL48z rlIQ== X-Gm-Message-State: AA6/9Rk96b9QebIa1NkDhvEAq+YSb20bXefzfnpWdEYifVrSIUvXg9k7TEK/QhQ/8cUOymwxNr+kYVLvIyx2uQ== X-Received: by 10.157.29.229 with SMTP id w34mr13008777otw.62.1475856284614; Fri, 07 Oct 2016 09:04:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.248 with HTTP; Fri, 7 Oct 2016 09:04:43 -0700 (PDT) From: Mary Barnes Date: Fri, 7 Oct 2016 11:04:43 -0500 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary=001a113ce2349586f9053e48914f Archived-At: Subject: [dispatch] Two week review: Progressing draft-mohali-dispatch-originating-cdiv-parameter as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 16:04:47 -0000 --001a113ce2349586f9053e48914f Content-Type: text/plain; charset=UTF-8 Hi all, This email starts a 2 week review with regards to progressing this document as AD sponsored. Please respond no later than October 21, 2016 as to whether or not you support this document being progressed as AD sponsored. Please provide reasons and details if you do not support the progression of the document. Regards, Mary Barnes DISPATCH WG co-chair On Tue, Sep 27, 2016 at 8:40 AM, wrote: > Hi, > > I've added indication into ABNF section (trying to catch Anton's comment), > removed the brackets in the Abstract and few other editorial changes in > this new version (-02) of the draft. > URL: https://www.ietf.org/internet- > drafts/draft-mohali-dispatch-originating-cdiv-parameter-02.txt > > > Best Regards, > Marianne > > --001a113ce2349586f9053e48914f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

This email starts a 2 week revi= ew with regards to progressing this document as AD sponsored.
Please respond no later than O= ctober 21, 2016 as to whether or not you support this document being progre= ssed as=C2=A0AD<= /span>=C2=A0sponsored. =C2=A0 Please provi= de reasons and details if you do not support the progression of the documen= t.=C2=A0

Regards,
Mary Barnes=
DISPATCH WG co-chair


On Tue, Sep 27, 2016 at 8:40 AM, <marianne.mohali@orange.com> wrote:
Hi,

I've added indication into ABNF section (trying to catch Anton's co= mment), removed the brackets in the Abstract and few other editorial change= s in this new version (-02) of the draft.
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dr= afts/draft-mohali-dispatch-originating-cdiv-parameter-02.txt<= br>

Best Regards,
Marianne

--001a113ce2349586f9053e48914f-- From nobody Fri Oct 7 10:23:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDBC129695 for ; Fri, 7 Oct 2016 10:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 5A-kEtI0bGJC for ; Fri, 7 Oct 2016 10:23:01 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D797912967D for ; Fri, 7 Oct 2016 10:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EUz/1SR0+KeziZm1htADkpb33n0kCgC+byzZ07V/a+I=; b=nz1+skYw0rJLXeZQ6+EXZ33b5piYFduYR6OXqLXilImn71uMj8vH7LEajAD8tgfBiU48P4T0SuHYfFkbMtVA3VVp5C76ZpffXVn6RZhborIs16saXqBO8TNNw4+yO5rADIU8eLMcM7gG6VQ8a3mZ2neOcSNn8For4nUIEz9q68M= From: Henning Schulzrinne To: "Dale R. Worley" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWijqIJi1PJIEa3EccQvSjRiaCdO86d Date: Fri, 7 Oct 2016 17:22:56 +0000 Message-ID: References: (Henning.Schulzrinne@fcc.gov),<87y4205jkr.fsf@hobgoblin.ariadne.com> In-Reply-To: <87y4205jkr.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: f0fd7c5d-e4cc-46df-9ed4-08d3eed69481 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 6:gUtl7fnrUKxZg78ubVxcWlCAUaC6g1hLdmtv6JsQqeURovvTfEbVkyy5d2qvL+pxzquQG49XT4bO5BbHQSlJpWGiGB2Z4i24w57V98tla/xLUf4XAGVQzk46LU92qtYv1XpzC07UtT7Mk0e/RMkqpl0SJo4m7RPjUmz6FUX6V4Sgzt06Z/DIO1OMADs8GrC+/MNipy729EeAgKuYSAo5yznnkM8r/qPuSOyAFMUEayb5dGjBQmqqyOxVRKhu10XCD+UHEwD98AtjF9Fauk31SkafmsedXI8BOkpi9tWrXwbWxO/J9bBuLyM4w9/Nc0Kv; 5:tOmTwYeYPlI9z23v4B4xUgNr7FF+2jPa0Wd5GaKL/UVnSqRMVoQO3Vl/SAZDxxNhm15bG4m41A/+o7JsmefK+J781462ETnpE9ew2IHIEtQQDTKu2bIyx2gvaw6/I26VAAHD8x2jV706dPET5Cd0qLO4AtUHuW2UCTIF8VdxFvo=; 24:yKb0BEeWSguZ74gnTk4O22i83e7koaqighEB/0b1YlYbPLB8buadpMcH4HWbvQJiHnDeah9janbZ3sce0/OF/X0qiXmgpL3ViV7BQzVFUGM=; 7:7b4Rg/8LyQgAdcnEsp4lTfARA5Bjl9nXKhqES2IsGkQsHsPrDqoinrWlna530RygwaMpoI4G+AiSb4TKDgYkj8DfD4OKSj5FI7aCBaigVl5LkNB9U3yZzgkJ2jXXRRVnpv7aPfQKD29ciCBYXf2enfzjGWcxyvMYFJSyWOoi1aJxcR/lZvLX8msj9sh/kzEuRISnxHmFcruZDi+GwK16IuLemRtaAm0ACowzlaYTMAH2httyYwH0291TMdpKiP6pDcwRyDL045JvQ9wVIHv5GPzynTLQdRu58kxxiiiJx7Sv/ryWB+EnH88tXN+W2bIKiFAWbIQvUWknU6DBRwg8ig== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(189002)(9686002)(586003)(7736002)(19625215002)(3900700001)(86362001)(6606003)(19580395003)(33656002)(10400500002)(2900100001)(7846002)(6116002)(102836003)(106356001)(74316002)(19580405001)(68736007)(87936001)(77096005)(122556002)(92566002)(5002640100001)(76576001)(7696004)(110136003)(8936002)(2906002)(8676002)(81166006)(105586002)(5660300001)(81156014)(101416001)(99286002)(6916009)(2950100002)(54356999)(189998001)(19627405001)(16236675004)(97736004)(3280700002)(76176999)(50986999)(11100500001)(4326007)(3660700001)(106116001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06346BB4ADBC157E5B384BCFEAC60CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 17:22:56.8384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:23:04 -0000 --_000_CY1PR09MB06346BB4ADBC157E5B384BCFEAC60CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this is a 95/5 problem. In almost all practical -- residential, PBX= or mobile, circumstances, the called party can be nearly certain that it i= s identified by the To header field and that there is no forking to other s= ubscribers (there may be forking to other devices, such as simul-ring, but = those can safely be assumed to share the same "opinion" about the call). Can you provide a practical, deployed example where this is not the case? Y= ou seem to have cases in mind that I can't think of. I agree that this caution should be called out, so maybe you can suggest so= me suitable text that indicates the applicability. Would some version of "T= his SHOULD only be used in use cases where each call only reaches a single = logical subscriber, such as a single residential subscriber phone number, r= ather than administratively independent entities?" ________________________________ From: Dale R. Worley Sent: Friday, October 7, 2016 10:18 AM To: Henning Schulzrinne Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts Henning Schulzrinne writes: > The whole point of the "Unwanted" response is > exactly that the UAC is making a decision on behalf of the destination > number and all associated destinations (UACs). OTOH, my point is that the 6xx response applies to all forks of the called number, which may not be the destination number. In fact, the called UA doesn't *know* the called number. > It does want any forking to stop immediately. It never wants to hear > from the number again, on any device associated with the destination > number. This is meant for single-person/household/office tel URIs as > the common use case, but maybe there are cases (some kind of group > destination?) we need to carve out where this should not be used. There are an infinite number of possibilities. I expect the commonest case is for all possible destinations of a call to be under control of one person or organization, but there's no requirement for that in SIP. Dale --_000_CY1PR09MB06346BB4ADBC157E5B384BCFEAC60CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think this is a 95/5 problem. In almost all practical -- resident= ial, PBX or mobile, circumstances, the called party can be nearly certain t= hat it is identified by the To header field and that there is no forking to= other subscribers (there may be forking to other devices, such as simul-ring, but those can safely be assumed to s= hare the same "opinion" about the call).


Can you provide a practical, deployed example where this is not the case= ? You seem to have cases in mind that I can't think of.


I agree that this caution should be called out, so maybe you can suggest= some suitable text that indicates the applicability. Would some version of= "This SHOULD only be used in use cases where each call only= reaches a single logical subscriber, such as a single residential subscriber phone number, rather than administratively i= ndependent entities?"


From: Dale R. Worley <= worley@ariadne.com>
Sent: Friday, October 7, 2016 10:18 AM
To: Henning Schulzrinne
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts
 
Henning Schulzrinne <Henning.Schulzrinne@fcc.go= v> writes:

> The whole point of the "Unwanted" response is
> exactly that the UAC is making a decision on behalf of the destination=
> number and all associated destinations (UACs).

OTOH, my point is that the 6xx response applies to all forks of the
called number, which may not be the destination number.  In fact, the<= br> called UA doesn't *know* the called number.

> It does want any forking to stop immediately. It never wants to hear > from the number again, on any device associated with the destination > number. This is meant for single-person/household/office tel URIs as > the common use case, but maybe there are cases (some kind of group
> destination?) we need to carve out where this should not be used.

There are an infinite number of possibilities.  I expect the commonest=
case is for all possible destinations of a call to be under control of
one person or organization, but there's no requirement for that in SIP.

Dale

--_000_CY1PR09MB06346BB4ADBC157E5B384BCFEAC60CY1PR09MB0634namp_-- From nobody Fri Oct 7 10:25:17 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9784F129508; Fri, 7 Oct 2016 10:25:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147586111557.8987.5620444872577192910.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2016 10:25:15 -0700 Archived-At: Cc: ben@nostrum.com, dispatch@ietf.org, smccammon@amsl.com, dispatch-chairs@ietf.org Subject: [dispatch] dispatch - Update to a Meeting Session Request for IETF 97 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:25:15 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 175 Conflicts to Avoid: First Priority: appsawg core clue bfcpbis avtext avtcore apparea dbound ecrit insipid mmusic netvc p2psip payload rmcat rtcweb sipcore siprec stir stox straw webpush xrblock Second Priority: tram tsvwg tsvarea opsarea lmap Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Fri Oct 7 12:55:50 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B8B1293E9 for ; Fri, 7 Oct 2016 12:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 liaFHyK3QKCI for ; Fri, 7 Oct 2016 12:55:45 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 54A1E1293E3 for ; Fri, 7 Oct 2016 12:55:45 -0700 (PDT) Received: (qmail 26680 invoked by uid 0); 7 Oct 2016 19:55:44 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy2.mail.unifiedlayer.com with SMTP; 7 Oct 2016 19:55:44 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id sjqf1t0181MNPNq01jqit2; Fri, 07 Oct 2016 13:50:44 -0600 X-Authority-Analysis: v=2.1 cv=IecUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=1Z4slDfhAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=ZumPtrcF8C44j2dqeCoA:9 a=Ac_6e4RyjEax6v43:21 a=zHB5svAp7Cd9xflW:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=_Fszbdv8evYA:10 a=JwPPQSbBbIoe0w3YtMrH:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=ef56qr_8hkesV0SKvPxj:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=aFsFKb5ACiR0nD/aua4TWsdGIRe4puqi1qqGWVai+iE=; b=Jgd39PNJewHy7Sl71AKq+5W+F/ RVwIRyWPRTd+j/ntSoThijajIuNhcljCl1YYKwpy05W7NuPf9wtqHbeXrZAB9ZZd8CJfQEZOBQPYy 9Qy6+OM20QgjWvMgsE5qogvPk; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:51178 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bsafI-0002kR-Eb; Fri, 07 Oct 2016 13:18:40 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 15:18:38 -0400 From: Richard Shockey To: Michael Hammer , "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Message-ID: <4C7ACBE9-A679-4EDF-8963-EA6F7964DEFC@shockey.us> Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BD03E98A@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BD03E98A@sc9-ex2k10mb1.corp.yaanatech.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bsafI-0002kR-Eb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:51178 X-Source-Auth: richard+shockey.us X-Email-Count: 6 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:55:49 -0000 Right .. and if you want to see some preliminary thinking on what a UI migh= t look like you can look at this. http://www.nanc-chair.org/docs/mtg_docs/Sep16_Robocall_Spoofing_Concepts.pd= f I can assure you that there is a whole mob starting to zero in on the UI is= sue.=20 Trending Film at 11.=20 We need the protocol element. The STIR/SHAKEN construct is useless without= consumer signaling. Some of us have been kicking around similar ideas in t= he back channel for months. I totally support adoption of Henning=E2=80=99s drafts. Hopefully there is conse= nsus that we don=E2=80=99t need a new WG for this. I do NOT support a new WG. Th= e need is so critical and the potential for immediate adoption is so great w= e need to move this along perhaps in some other way. =20 Personally I=E2=80=99m totally in favor of 666. I thought that might work for a = proposed Psuedo-ANI code for identifying international call gateways. =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 10/7/16, 11:33 AM, "dispatch on behalf of Michael Hammer" wrote: Paul, =20 Understand. But, this is chicken or egg issue. An app developer can't do the UI without the protocol element to make i= t useful. =20 Agree with thought that a single "spam" button may be enough of an indicator. Operator would have to decide at what statistical level to start taggin= g new calls with "possible spam" label. =20 ________________________________ Michael Hammer michael.hammer@yaanatech.com +1 408 202 9291 =20 =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentia= lity notice. This message is private and confidential. If you have received = this message in error, please notify us and remove it from your system. =20 -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyz= ivat Sent: Thursday, October 06, 2016 2:34 PM To: dispatch@ietf.org Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) =20 On 10/6/16 1:48 PM, Michael Hammer wrote: > I like the idea of a unique non-overloaded code point that > > can be used to drive some peg-counts or big data analysis of calls > > to highlight the numbers and rates in real-time, so that > > systems could proactively tag next calls to say to called user > > that this next call had 100,000 users saying it was a robo-call. =20 This would be nice. But it depends on more than a unique response code.= =20 It also needs for users to only use that code for the semantic you want= to tag it with. This depends as much on the UI provided to users as it doe= s on the existence of the code(s). =20 Of necessity the UI will be simple, with few choices for how to reject = a call. (I guess one or possibly two.) Those can then be mapped to partic= ular response codes. But it will be hard to get users to use those buttons f= or precisely the semantics we want to ascribe to the codes. (Do we we want= the button to mean "unwanted robo-call", "call from undesired caller", "objectionable call content", or what?) =20 Even though the IETF doesn't "do" UIs, it might be better to discuss th= e likely UI before fully defining the code(s). =20 Thanks, Paul =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 From nobody Fri Oct 7 13:18:13 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5522D12970D for ; Fri, 7 Oct 2016 13:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] 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 CRW729NwTFwT for ; Fri, 7 Oct 2016 13:18:11 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 054241296FA for ; Fri, 7 Oct 2016 13:18:10 -0700 (PDT) X-AuditID: 12074413-991ff70000000a14-85-57f803028b42 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 51.49.02580.20308F75; Fri, 7 Oct 2016 16:18:10 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u97KI9kt015325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 7 Oct 2016 16:18:09 -0400 To: dispatch@ietf.org References: <87y4205jkr.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Fri, 7 Oct 2016 16:18:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87y4205jkr.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixO6iqMvE/CPcYMsfCYulkxawOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/dPnYJO9oo5m26yNjCeZO1i5OSQEDCRON+9kbmLkYtDSOAy o8S5TYehnHdMEssWnmQEqRIWMJB4MmUjC4gtIiAqMX/FInYQW0jASOLf0+Vgk9gEtCTmHPoP VsMrYC/x5fY9JhCbRUBFYv/1OWA1ogJpEtvX7WaGqBGUODnzCVg9p4CxxKQ5R8HqmQVsJe7M hahhFpCX2P52DvMERr5ZSFpmISmbhaRsASPzKka5xJzSXN3cxMyc4tRk3eLkxLy81CJdc73c zBK91JTSTYyQIBPewbjrpNwhRgEORiUeXoH138OFWBPLiitzDzFKcjApifK+rAQK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuH9yPgjXIg3JbGyKrUoHyYlzcGiJM6rtkTdT0ggPbEkNTs1tSC1 CCYrw8GhJMG7FKRRsCg1PbUiLTOnBCHNxMEJMpwHaPgOsOHFBYm5xZnpEPlTjLocC37cXssk xJKXn5cqJc7bCFIkAFKUUZoHNweWHF4xigO9Jcz7A6SKB5hY4Ca9AlrCBLQkf+kXkCUliQgp qQZGxZ/xFntfPM0K/nLzFfdVn74tx+QTpD1+175+Kfi74oXcQ+Gfd0TvP/W+16nY69K643n+ 3Uy3M0vVKr917tnYkpkkMqeCfSXn64efT+802Zf7UbCbKW7nDB6e1Uu7Xzzfc22617rU3avd YiKW9bAKMqTtV+VxDbVdMUXG9j0z581On90Ke9mUlFiKMxINtZiLihMB4b+C2OkCAAA= Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:18:12 -0000 On 10/7/16 10:18 AM, Dale R. Worley wrote: > Henning Schulzrinne writes: > >> The whole point of the "Unwanted" response is >> exactly that the UAC is making a decision on behalf of the destination >> number and all associated destinations (UACs). > > OTOH, my point is that the 6xx response applies to all forks of the > called number, which may not be the destination number. In fact, the > called UA doesn't *know* the called number. An interesting point. If my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, does that get handled as *my* preference? If the spam filtering is handled by the same intermediary as the one handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be difficult to tell. Thanks, Paul From nobody Fri Oct 7 13:20:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A523129423 for ; Fri, 7 Oct 2016 13:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] 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 6dPJ6iZ5beq6 for ; Fri, 7 Oct 2016 13:20:47 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E708712966C for ; Fri, 7 Oct 2016 13:20:43 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u97KFI1g014996; Fri, 7 Oct 2016 16:20:42 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 25xgqrk41w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Oct 2016 16:20:41 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u97KKfGS021620; Fri, 7 Oct 2016 16:20:41 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u97KKaJl021564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Oct 2016 16:20:37 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 7 Oct 2016 20:20:22 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.250]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 16:20:22 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWi2HwzrKjG+EiQ+j755/EMs6CdsZqA//+9kI0= Date: Fri, 7 Oct 2016 20:20:21 +0000 Message-ID: <3E08DF84-6D61-43B4-ADDD-4CBB591AB58F@att.com> References: <87y4205jkr.fsf@hobgoblin.ariadne.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3E08DF846D6143B4ADDD4CBB591AB58Fattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610070349 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:20:50 -0000 --_000_3E08DF846D6143B4ADDD4CBB591AB58Fattcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 7, 2016, at 4:18 PM, Paul Kyzivat > wrote: On 10/7/16 10:18 AM, Dale R. Worley wrote: Henning Schulzrinne > writes: The whole point of the "Unwanted" response is exactly that the UAC is making a decision on behalf of the destination number and all associated destinations (UACs). OTOH, my point is that the 6xx response applies to all forks of the called number, which may not be the destination number. In fact, the called UA doesn't *know* the called number. An interesting point. If my calls are forwarded to a colleague while I am o= n vacation, and he rejects a caller, does that get handled as *my* preferen= ce? If the spam filtering is handled by the same intermediary as the one handli= ng the forwarding then presumably it can be sorted out. But if the filterin= g is done upstream from where the forwarding is done it may be difficult to= tell. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_3E08DF846D6143B4ADDD4CBB591AB58Fattcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Oct 7, 2016, at 4:18 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 10/7/16 10:18 AM, Dale R. Worley wrote:
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> writes:

The whole point of the "Unwanted"= response is
exactly that the UAC is making a decision o= n behalf of the destination
number and all associated destinations (UAC= s).

OTOH, my point is that the 6xx response app= lies to all forks of the
called number, which may not be the destina= tion number.  In fact, the
called UA doesn't *know* the called number.=

An interesting point. If my calls are forwarded to a colleague while = I am on vacation, and he rejects a caller, does that get handled as *my* pr= eference?

If the spam filtering is handled by the same intermediary as the one = handling the forwarding then presumably it can be sorted out. But if the fi= ltering is done upstream from where the forwarding is done it may be diffic= ult to tell.

   Thanks,
   Paul



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_3E08DF846D6143B4ADDD4CBB591AB58Fattcom_-- From nobody Fri Oct 7 13:31:24 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC2E129547 for ; Fri, 7 Oct 2016 13:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 NStibInCvXY4 for ; Fri, 7 Oct 2016 13:31:20 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E14129412 for ; Fri, 7 Oct 2016 13:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SizppWiSCsQNlc5PsQFiqu5BBvc/mv/G1Eqt2ZtVJyk=; b=TLpnbZuWMs+4nOtcpymXcWWXrio3XF95KuPc81+EuMfHqNRODS5OoZHbVYjUd/4HqrS4yKKfXOIV1i/6ECRImi2shJM38/B6c8yqF6rQwjKPtrGD4B3tUd9MCtKw54JB31kXsDJBEUeTjbLh8ZHMYpnvglbeuIx9Vb5p2d8e2Fs= From: Henning Schulzrinne To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWijqIJi1PJIEa3EccQvSjRiaCdbouAgAAB3oc= Date: Fri, 7 Oct 2016 20:31:15 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 22667897-e019-46bf-61fb-08d3eef0e330 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:v5tSOaAdp00dNihkj7VD6pewgMCzmx8/7z6kaxYG/fK4bK0uLyjh7mMBkHjkueINWGGDgHb3kVXRHEL2QEaumzYt+k0tJ4HiDwmf4qpYOZeXobtki8S+qDRwmcs6VC+ifwXg3z9VyckA0SHhc8h1+BLoOOH8ACRHA/cPOYm7FsluC364oFT4Pn9wY5109ZGP/f9MTXIzMEbaRpd4li5cj5HgbtrVZxishFYTOTtoiaqGCmk+kDejXNpFZ0DMj4JJbjcsREkemokc9FgwQ2VMQeOYKLVBpNhKJUVjMsYBCLJ5ZZT08O/Pv0wcJDYImLov; 5:NsuSEERVslrLXSpKXhuMEH6YVUQ1o/IB9icRHRqsIp6vh0oJKF/ogUvvG0OpyV1dH9lOQ5MLla0KQ/216yrude4+xL7RyEZ9wIg19SxS4lgBEMZejYad6G5KNDpAR8hdxt9QmgBaf15Nq3Aj/1E6QG1f7a/rgpxTKOxVBzhEjuY=; 24:MnAIIdbFiiCZhW4lekyr7lBl0lIGSVpoZmPXHHQw42Lx7S8Jg6Vi9V/6RPFWRF/6UoicIIuHY8mwC3UF/fQUfWa6NfVTIPp2akXMgP8GAUA=; 7:p5v0hGpGDfpIzfelQp7Gh1tH2bvgQp/iQgQy/XCril9/ItpUiCIpx+ZCIMX7qSGKtomzwLLbK3PpPSrpSUkQhYBsh/ebB378bU40BGGzjPHBkphTgwCWf8Nb81BaxnR/jU2GxRQnAIljbPFy29XHoO/mIGMUkImQ7gxFwZEMhxMRytz9Zv8dUx683bfrf5p27AE0GTYqfF046bBIlBte7pjckiq0Umcf0t75pMuTaxhOjVCGqEyRn8oHNzm6VU/ElYBXgIR5aEeyl7PQzgDGYO81Q7RjSVLhHkOY0AGvcwixCJTdAo95h9KKKaNum9cary3kMXIw8ddPizVhUMwP5w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(189002)(377454003)(11100500001)(7696004)(77096005)(3280700002)(8936002)(10400500002)(92566002)(2900100001)(19580395003)(19580405001)(15975445007)(76176999)(9686002)(122556002)(19625215002)(33656002)(19617315012)(5002640100001)(2501003)(5660300001)(16236675004)(107886002)(189998001)(97736004)(5001770100001)(50986999)(74316002)(54356999)(2950100002)(8676002)(7906003)(7846002)(105586002)(106116001)(81166006)(81156014)(7736002)(76576001)(106356001)(99286002)(101416001)(3660700001)(586003)(6116002)(102836003)(2906002)(87936001)(2171001)(86362001)(68736007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06344081C19957DA4146D05AEAC60CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 20:31:15.7990 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:31:22 -0000 --_000_CY1PR09MB06344081C19957DA4146D05AEAC60CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would argue that, practically speaking, there's not much difference. This= is a statistical indicator, so whether this truly speaks for the principal= or his/her vacation sub seems only important at the margins. You could als= o argue that if you don't trust your colleague to recognize spam calls, you= may not want him or her to answer calls for you. You may even answer one o= f the "industry thought leader" survey calls for that person... Things get slightly trickier if 666 triggers addition to a personal blackli= st. Even here, I'd argue that this makes sense. If my colleague is kind eno= ugh to answer my calls for the next two weeks, she has every right not to b= e bothered by the same nuisance caller multiple times. I do run the risk th= at I won't get out of the next speeding ticket since she didn't contribute = to the Police Benevolence Association. ________________________________ From: dispatch on behalf of Paul Kyzivat Sent: Friday, October 7, 2016 4:18:09 PM To: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts On 10/7/16 10:18 AM, Dale R. Worley wrote: > Henning Schulzrinne writes: > >> The whole point of the "Unwanted" response is >> exactly that the UAC is making a decision on behalf of the destination >> number and all associated destinations (UACs). > > OTOH, my point is that the 6xx response applies to all forks of the > called number, which may not be the destination number. In fact, the > called UA doesn't *know* the called number. An interesting point. If my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, does that get handled as *my* preference? If the spam filtering is handled by the same intermediary as the one handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be difficult to tell. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CY1PR09MB06344081C19957DA4146D05AEAC60CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would argue that, practically speaking, there's not much difference. T= his is a statistical indicator, so whether this truly speaks for the princi= pal or his/her vacation sub seems only important at the margins. You c= ould also argue that if you don't trust your colleague to recognize spam calls, you may not want him or her to ans= wer calls for you. You may even answer one of the "industry thought le= ader" survey calls for that person...


Things get slightly trickier if 666 triggers addition to a personal blac= klist. Even here, I'd argue that this makes sense. If my colleague is kind = enough to answer my calls for the next two weeks, she has every right = not to be bothered by the same nuisance caller multiple times. I do run the risk that I won't get out of the next = speeding ticket since she didn't contribute to the Police Benevolence Assoc= iation.

From: dispatch <dispat= ch-bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu= >
Sent: Friday, October 7, 2016 4:18:09 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts
 
On 10/7/16 10:18 AM, Dale R. Worley wrote:
> Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> writes:
>
>> The whole point of the "Unwanted" response is
>> exactly that the UAC is making a decision on behalf of the destina= tion
>> number and all associated destinations (UACs).
>
> OTOH, my point is that the 6xx response applies to all forks of the > called number, which may not be the destination number.  In fact,= the
> called UA doesn't *know* the called number.

An interesting point. If my calls are forwarded to a colleague while I
am on vacation, and he rejects a caller, does that get handled as *my*
preference?

If the spam filtering is handled by the same intermediary as the one
handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be
difficult to tell.

        Thanks,
        Paul



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

 --_000_CY1PR09MB06344081C19957DA4146D05AEAC60CY1PR09MB0634namp_-- From nobody Fri Oct 7 13:32:59 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7712967A for ; Fri, 7 Oct 2016 13:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 4_2Nc0OSD-k4 for ; Fri, 7 Oct 2016 13:32:56 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5181295CE for ; Fri, 7 Oct 2016 13:32:56 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with SMTP id sbo9bq2Kp8GkCsbp9br4zA; Fri, 07 Oct 2016 20:32:55 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-19v.sys.comcast.net with SMTP id sbp8bhAliOIozsbp9b4OK8; Fri, 07 Oct 2016 20:32:55 +0000 To: Richard Shockey , Michael Hammer , "dispatch@ietf.org" References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BD03E98A@sc9-ex2k10mb1.corp.yaanatech.com> <4C7ACBE9-A679-4EDF-8963-EA6F7964DEFC@shockey.us> From: Paul Kyzivat Message-ID: Date: Fri, 7 Oct 2016 16:32:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4C7ACBE9-A679-4EDF-8963-EA6F7964DEFC@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfKrsu+nZual1bltgWiBir7DOxTdrc/lNZ3aBwcVrXLucyQstx8FG+trgH9YiNAzC0QlTlcRytixTzIYGBGTYYu2rrk1bP/41+5ktRRBZlZiPj32LR5jB SXtxhkGnRdbpDbFfFxe+nA0mhf/LF5NvhljDk5U5u6hDhPNeHLW84fHiLjTbJTXZkn8ldsAaLNei9cCzWA5ke2eCmkLYRkSu6ROGAirRVjAwQM3xLk2P7X9C ttajO7tdtQ+RoQQe8k8I+g== Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:32:58 -0000 On 10/7/16 3:18 PM, Richard Shockey wrote: > > Right .. and if you want to see some preliminary thinking on what a UI might look like you can look at this. > > http://www.nanc-chair.org/docs/mtg_docs/Sep16_Robocall_Spoofing_Concepts.pdf > > I can assure you that there is a whole mob starting to zero in on the UI issue. > > Trending Film at 11. > > We need the protocol element. The STIR/SHAKEN construct is useless without consumer signaling. Some of us have been kicking around similar ideas in the back channel for months. I agree - one is needed. The problem will arise if the meaning implied by the UI is different from the meaning specified for the response code. Most people don't read a user guide, much less an RFC, to learn the meaning of a UI element. They intuit the meaning, or have it informally explained to them by somebody. So the intuitive meaning had better align with the response code. That may mean we have to define the code point while waffling on its precise semantics. Thanks, Paul > I totally support adoption of Henning’s drafts. Hopefully there is consensus that we don’t need a new WG for this. I do NOT support a new WG. The need is so critical and the potential for immediate adoption is so great we need to move this along perhaps in some other way. > > Personally I’m totally in favor of 666. I thought that might work for a proposed Psuedo-ANI code for identifying international call gateways. > > > — > Richard Shockey > > Shockey Consulting LLC > > Chairman of the Board SIP Forum > > www.shockey.us > > www.sipforum.org > > richardshockey.us > > Skype-Linkedin-Facebook rshockey101 > > PSTN +1 703-593-2683 > > > > On 10/7/16, 11:33 AM, "dispatch on behalf of Michael Hammer" wrote: > > Paul, > > Understand. But, this is chicken or egg issue. > An app developer can't do the UI without the protocol element to make it > useful. > > Agree with thought that a single "spam" button may be enough of an > indicator. > Operator would have to decide at what statistical level to start tagging new > calls with "possible spam" label. > > ________________________________ > Michael Hammer > michael.hammer@yaanatech.com > +1 408 202 9291 > > © 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality > notice. This message is private and confidential. If you have received this > message in error, please notify us and remove it from your system. > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, October 06, 2016 2:34 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) > > On 10/6/16 1:48 PM, Michael Hammer wrote: > > I like the idea of a unique non-overloaded code point that > > > > can be used to drive some peg-counts or big data analysis of calls > > > > to highlight the numbers and rates in real-time, so that > > > > systems could proactively tag next calls to say to called user > > > > that this next call had 100,000 users saying it was a robo-call. > > This would be nice. But it depends on more than a unique response code. > It also needs for users to only use that code for the semantic you want to > tag it with. This depends as much on the UI provided to users as it does on > the existence of the code(s). > > Of necessity the UI will be simple, with few choices for how to reject a > call. (I guess one or possibly two.) Those can then be mapped to particular > response codes. But it will be hard to get users to use those buttons for > precisely the semantics we want to ascribe to the codes. (Do we we want the > button to mean "unwanted robo-call", "call from undesired caller", > "objectionable call content", or what?) > > Even though the IETF doesn't "do" UIs, it might be better to discuss the > likely UI before fully defining the code(s). > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > From nobody Fri Oct 7 13:44:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7C12945F for ; Fri, 7 Oct 2016 13:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 AHPcw7KJvEaz for ; Fri, 7 Oct 2016 13:44:42 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCA312940F for ; Fri, 7 Oct 2016 13:44:42 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-11v.sys.comcast.net with SMTP id sbyyb5iWalSxssc0YbRef7; Fri, 07 Oct 2016 20:44:42 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-18v.sys.comcast.net with SMTP id sc0XbGOomZx9Ssc0XbbrP6; Fri, 07 Oct 2016 20:44:42 +0000 To: "DOLLY, MARTIN C" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <3E08DF84-6D61-43B4-ADDD-4CBB591AB58F@att.com> From: Paul Kyzivat Message-ID: <6e8f5bcd-9f82-9c28-4dff-0acbec0c5fe7@alum.mit.edu> Date: Fri, 7 Oct 2016 16:44:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3E08DF84-6D61-43B4-ADDD-4CBB591AB58F@att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfIk7TRjKUDL2dRiG3fpFXe9Nn7RQt29lCXvq9pMLZEmxdfgkeKJgog9JogRslI5D+7tkTmaCJIZgS6OLSYCz4OuegtMZemMTcc4Ws2FRaUQGXwfl4G5P 7fM7SQo+4kR3L7xUueF2R1lSmDX+ATurcs9mYg+cb8xC4LNm3USqHV1QGZpJjAPYC7CyzTY2221jo+8774ajcQkJnVjH/VDVoVQ= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:44:44 -0000 Martin, On 10/7/16 4:20 PM, DOLLY, MARTIN C wrote: > No Your one-word answers aren't helpful! They add nothing but noise to the conversation. I have no idea what your "No" means? I figure it could be any of the following: 1) No - its not an interesting point. (Why?) 2) No - if my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, it does *not* get treated as *my* preference. (In which case my later point about filtering being handled upstream of forwarding becomes important.) 3) No - if filtering is done upstream from where the forwarding is done it *won't* be difficult to tell. (Why not?) 4) No - you don't consider comments from Paul as deserving a thoughtful answer. Paul > *Martin C. Dolly* > > Lead Member of Technical Staff > > Core & Government/Regulatory Standards > > AT&T > > Cell: +1.609.903.3360 > > Email: _md3135@att.com _ > > > > > On Oct 7, 2016, at 4:18 PM, Paul Kyzivat > wrote: > >> On 10/7/16 10:18 AM, Dale R. Worley wrote: >>> Henning Schulzrinne >> > writes: >>> >>>> The whole point of the "Unwanted" response is >>>> exactly that the UAC is making a decision on behalf of the destination >>>> number and all associated destinations (UACs). >>> >>> OTOH, my point is that the 6xx response applies to all forks of the >>> called number, which may not be the destination number. In fact, the >>> called UA doesn't *know* the called number. >> >> An interesting point. If my calls are forwarded to a colleague while I >> am on vacation, and he rejects a caller, does that get handled as *my* >> preference? >> >> If the spam filtering is handled by the same intermediary as the one >> handling the forwarding then presumably it can be sorted out. But if >> the filtering is done upstream from where the forwarding is done it >> may be difficult to tell. >> >> Thanks, >> Paul >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Oct 7 13:52:40 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6D212941E for ; Fri, 7 Oct 2016 13:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 BPeA0_P5fbhU for ; Fri, 7 Oct 2016 13:52:38 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9FA129405 for ; Fri, 7 Oct 2016 13:52:38 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with SMTP id sc77bq3ro8GkCsc8Dbr7zN; Fri, 07 Oct 2016 20:52:37 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-12v.sys.comcast.net with SMTP id sc8CbMaqxjKdBsc8CbfodX; Fri, 07 Oct 2016 20:52:37 +0000 To: Henning Schulzrinne , "dispatch@ietf.org" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Fri, 7 Oct 2016 16:52:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLtYN1cV1bsesVxflp01immogVsu5ma8eufKmlpABeDc45QR5akmYqmqXscM4rD2gECznUk4Z7HeybZH/LTJBe7flmLdHFo56XAhIHvAwgerYimKsMKD KiSF+I1KtYSRMrb5vnmnqbHCW+uJIk5q4Yjk53Wi6qk77gMDozYHPgpGUTlb6MoRLsTi8EWVVvaLgSE0YESaNxliisQdMwZF9CQ= Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:52:39 -0000 On 10/7/16 4:31 PM, Henning Schulzrinne wrote: > I would argue that, practically speaking, there's not much difference. > This is a statistical indicator, so whether this truly speaks for the > principal or his/her vacation sub seems only important at the margins. > You could also argue that if you don't trust your colleague to recognize > spam calls, you may not want him or her to answer calls for you. You may > even answer one of the "industry thought leader" survey calls for that > person... > > > Things get slightly trickier if 666 triggers addition to a personal > blacklist. Even here, I'd argue that this makes sense. If my colleague > is kind enough to answer my calls for the next two weeks, she has every > right not to be bothered by the same nuisance caller multiple times. I > do run the risk that I won't get out of the next speeding ticket since > she didn't contribute to the Police Benevolence Association. This depends a lot on how these responses get used. There is a significant difference between using this to get a statistical measure from the population as a whole, and building a personal black-list. I was thinking it might be used for both. What if the call to me was from my colleague's abusive spouse? I may still have a need to receive calls from that person even though my colleague does not. And I don't know if we can assume a forwardee will know that the incoming call has been forwarded. Thanks, Paul > ------------------------------------------------------------------------ > *From:* dispatch on behalf of Paul Kyzivat > > *Sent:* Friday, October 7, 2016 4:18:09 PM > *To:* dispatch@ietf.org > *Subject:* Re: [dispatch] Two new VoIP spam drafts > > On 10/7/16 10:18 AM, Dale R. Worley wrote: >> Henning Schulzrinne writes: >> >>> The whole point of the "Unwanted" response is >>> exactly that the UAC is making a decision on behalf of the destination >>> number and all associated destinations (UACs). >> >> OTOH, my point is that the 6xx response applies to all forks of the >> called number, which may not be the destination number. In fact, the >> called UA doesn't *know* the called number. > > An interesting point. If my calls are forwarded to a colleague while I > am on vacation, and he rejects a caller, does that get handled as *my* > preference? > > If the spam filtering is handled by the same intermediary as the one > handling the forwarding then presumably it can be sorted out. But if the > filtering is done upstream from where the forwarding is done it may be > difficult to tell. > > Thanks, > Paul > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Oct 7 13:56:24 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85B212941E for ; Fri, 7 Oct 2016 13:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] 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 DjmGhegGt1hG for ; Fri, 7 Oct 2016 13:56:20 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E8B129540 for ; Fri, 7 Oct 2016 13:56:18 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u97KtgnG013858; Fri, 7 Oct 2016 16:56:14 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 25xj2ehpn2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Oct 2016 16:56:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u97KuDJg005779; Fri, 7 Oct 2016 16:56:13 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u97Ku6SE005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Oct 2016 16:56:10 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 7 Oct 2016 20:55:52 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.250]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 16:55:52 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWi2HwzrKjG+EiQ+j755/EMs6CdsZqAgAADqYCAAAX3AP//vds7 Date: Fri, 7 Oct 2016 20:55:52 +0000 Message-ID: <79CFEE70-AB46-47E1-938F-8CFE990529C5@att.com> References: <87y4205jkr.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_79CFEE70AB4647E1938F8CFE990529C5attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610070361 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 20:56:23 -0000 --_000_79CFEE70AB4647E1938F8CFE990529C5attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable # goes on his blacklist if he has said service Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 7, 2016, at 4:52 PM, Paul Kyzivat > wrote: On 10/7/16 4:31 PM, Henning Schulzrinne wrote: I would argue that, practically speaking, there's not much difference. This is a statistical indicator, so whether this truly speaks for the principal or his/her vacation sub seems only important at the margins. You could also argue that if you don't trust your colleague to recognize spam calls, you may not want him or her to answer calls for you. You may even answer one of the "industry thought leader" survey calls for that person... Things get slightly trickier if 666 triggers addition to a personal blacklist. Even here, I'd argue that this makes sense. If my colleague is kind enough to answer my calls for the next two weeks, she has every right not to be bothered by the same nuisance caller multiple times. I do run the risk that I won't get out of the next speeding ticket since she didn't contribute to the Police Benevolence Association. This depends a lot on how these responses get used. There is a significant = difference between using this to get a statistical measure from the populat= ion as a whole, and building a personal black-list. I was thinking it might= be used for both. What if the call to me was from my colleague's abusive spouse? I may still = have a need to receive calls from that person even though my colleague does= not. And I don't know if we can assume a forwardee will know that the incoming c= all has been forwarded. Thanks, Paul ------------------------------------------------------------------------ *From:* dispatch > on behalf of Paul Kyzivat > *Sent:* Friday, October 7, 2016 4:18:09 PM *To:* dispatch@ietf.org *Subject:* Re: [dispatch] Two new VoIP spam drafts On 10/7/16 10:18 AM, Dale R. Worley wrote: Henning Schulzrinne > writes: The whole point of the "Unwanted" response is exactly that the UAC is making a decision on behalf of the destination number and all associated destinations (UACs). OTOH, my point is that the 6xx response applies to all forks of the called number, which may not be the destination number. In fact, the called UA doesn't *know* the called number. An interesting point. If my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, does that get handled as *my* preference? If the spam filtering is handled by the same intermediary as the one handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be difficult to tell. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_79CFEE70AB4647E1938F8CFE990529C5attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
# goes on his blacklist if he has said service

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Oct 7, 2016, at 4:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 10/7/16 4:31 PM, Henning Schulzrinne wrote:
I would argue that, practically speaking, t= here's not much difference.
This is a statistical indicator, so whether= this truly speaks for the
principal or his/her vacation sub seems onl= y important at the margins.
You could also argue that if you don't trus= t your colleague to recognize
spam calls, you may not want him or her to = answer calls for you. You may
even answer one of the "industry thoug= ht leader" survey calls for that
person...


Things get slightly trickier if 666 trigger= s addition to a personal
blacklist. Even here, I'd argue that this m= akes sense. If my colleague
is kind enough to answer my calls for the n= ext two weeks, she has every
right not to be bothered by the same nuisan= ce caller multiple times. I
do run the risk that I won't get out of the= next speeding ticket since
she didn't contribute to the Police Benevol= ence Association.

This depends a lot on how these responses get used. There is a signif= icant difference between using this to get a statistical measure from the p= opulation as a whole, and building a personal black-list. I was thinking it= might be used for both.

What if the call to me was from my colleague's abusive spouse? I may = still have a need to receive calls from that person even though my colleagu= e does not.

And I don't know if we can assume a forwardee will know that the inco= ming call has been forwarded.

   Thanks,
   Paul

-------------------------------------------= -----------------------------
*From:* dispatch <dispatch-bounces@ietf.org> on behalf of Paul = Kyzivat
<pkyzivat@alum.mit.edu>
*Sent:* Friday, October 7, 2016 4:18:09 PM<= /span>
*To:* = dispatch@ietf.org
*Subject:* Re: [dispatch] Two new VoIP spam= drafts

On 10/7/16 10:18 AM, Dale R. Worley wrote:<= /span>
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> writes:

The whole point of the "Unwanted"= response is
exactly that the UAC is making a decision o= n behalf of the destination
number and all associated destinations (UAC= s).

OTOH, my point is that the 6xx response app= lies to all forks of the
called number, which may not be the destina= tion number.  In fact, the
called UA doesn't *know* the called number.=

An interesting point. If my calls are forwa= rded to a colleague while I
am on vacation, and he rejects a caller, do= es that get handled as *my*
preference?

If the spam filtering is handled by the sam= e intermediary as the one
handling the forwarding then presumably it = can be sorted out. But if the
filtering is done upstream from where the f= orwarding is done it may be
difficult to tell.

       T= hanks,
       P= aul



___________________________________________= ____
dispatch mailing list
dispat= ch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_79CFEE70AB4647E1938F8CFE990529C5attcom_-- From nobody Fri Oct 7 14:05:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE9D129445 for ; Fri, 7 Oct 2016 14:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 o-3XAQ2aNXXA for ; Fri, 7 Oct 2016 14:05:23 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C1112941E for ; Fri, 7 Oct 2016 14:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lPYqcilDadJoPuQVP/TuaZHqyB25WblKyGP0carfcQk=; b=u8QnpzUjVlo0qLd6LKfh+r9Uva1sauiO9cfAdMlO5NwK/6RnqChAvsb+ntrT58DoqPiDlldw1lIt4oyg8Lj+35B3sP8UIXiLKzCwSREpOV80ql/8+dO+KBvyukKACxOkfk/V4ZqEwTnJ8yTOOXyXxkkvZMKhSZz3f7ShO0lUfkE= From: Henning Schulzrinne To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWijqIJi1PJIEa3EccQvSjRiaCdbouAgAAB3oeAAAfCAIAAAOj2 Date: Fri, 7 Oct 2016 21:05:18 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: e6c89031-12fc-4fd5-ec56-08d3eef5a4be x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 6:pUsQPFYVRQ6l5HnF0AnZI9Rr/8hR5f6+2gE1IoDRTGdhK7CHICtEcZH2VLaC9Jg6hycr2laygf6KGwTeR78qep305KiHpIU3f1Y6DXeUpxWD8KqXjrosO7ekQpSc1uDj6FoCgMbTpPdmwOtGnP6JnMYErai6h+6XeHjNYSaAj9ecMZPIGVYHbUkApxCKfNpQ5LTPljfBiX9DNds8szEAygR/j1I1gGkNr/qRsamghLYSgE07fS9/E0p4A6091Flh1hKezxxIY24ZgG/3147UAcGiKvQy7I2UIsRxKdCzn72gWkuCXrY+1UTXMgDt9geO; 5:G/zz5PI11iJcuQty4YujAzmD6EzOvg8w0/OD3s5GEqBEpjR/PIdzob+D18y/TFGKH7eH8KzXwAtoWZ8aGJGxfIcl/29P4vkf9KxAinhYJGbrF25HVSw8QtDwqSgFQTClQrYxHkhFIycgF5s3zbY51ECsRt6qwHkabxa3STmxnzw=; 24:Srvef07uSJeNGRCTjyEVUUz8bjG2KfLWzUmy1SiVX6qvT4+8s4nUtUuxMRgjTf49xDr6Zbwgk1ZhOqLYnHZ1EuXXXD8mko4RhH7z1QjIOqA=; 7:T0eWG9lRlsY0DhEMMdw3c5fLozcQMj14PMibFvxqIBK3829roYufy7E5+qt3gytbrtmF+UonJfAmsiozqrctLTWFDCP7mGtNG/M/AU1GFyHtE5/WKY3B1Lb/ddhWoX69SGcgR0LJV7dC62pCs3p9BYpz7sW0+Bst7njrN4Q18MaxNFNy1YF2gkWiCg+scHZ8LefDABwOg3Lx5jHaOdowA60nO9oixQIR737w8NH+8QqIZSUThjSWxxhgWvaBcRx29KKOX2I15Cid8UghW+B9+i/dgoYJbIqKuTo+bipMbFDDD+NBWyvcXMvTUdkVHWyysRgZ+kD3NVcdVAwrBUCiXA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(189002)(199003)(81166006)(8936002)(8676002)(81156014)(93886004)(122556002)(586003)(101416001)(2900100001)(2950100002)(97736004)(189998001)(77096005)(102836003)(2906002)(50986999)(92566002)(15975445007)(106356001)(105586002)(106116001)(6116002)(76576001)(54356999)(19617315012)(9686002)(5001770100001)(76176999)(68736007)(3280700002)(19580395003)(16236675004)(19625215002)(74316002)(3660700001)(2501003)(33656002)(19580405001)(5660300001)(10400500002)(7696004)(7736002)(7906003)(87936001)(86362001)(7846002)(2171001)(11100500001)(5002640100001)(107886002)(99286002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06348537268EBB7DAE80F59CEAC60CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2016 21:05:18.5604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 21:05:25 -0000 --_000_CY1PR09MB06348537268EBB7DAE80F59CEAC60CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you don't want your colleague to spam-mark your calls, you may want to t= ell her. Also, as a local implementation choice, the receiving UA may disab= le the "spam" button if the call (To) is not originally for that destinatio= n. Note that the same model works for email, and the world has lived. If I for= ward my email to a colleague, the spam button she uses may well trigger the= same (local and/or crowd-sourced) blacklisting. Users seem to understand spam buttons, recognizing that they occasionally l= ead to mistaken markings and some manual clean-up, such as the postmaster w= hitelisting or removing blacklisted addresses. I suspect there's only so much we can do for user-facing behavior. We seem = to agree that documenting these cases so that developers can make situation= ally-appropriate choices seems like a good idea. ________________________________ From: Paul Kyzivat Sent: Friday, October 7, 2016 4:52:36 PM To: Henning Schulzrinne; dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts On 10/7/16 4:31 PM, Henning Schulzrinne wrote: > I would argue that, practically speaking, there's not much difference. > This is a statistical indicator, so whether this truly speaks for the > principal or his/her vacation sub seems only important at the margins. > You could also argue that if you don't trust your colleague to recognize > spam calls, you may not want him or her to answer calls for you. You may > even answer one of the "industry thought leader" survey calls for that > person... > > > Things get slightly trickier if 666 triggers addition to a personal > blacklist. Even here, I'd argue that this makes sense. If my colleague > is kind enough to answer my calls for the next two weeks, she has every > right not to be bothered by the same nuisance caller multiple times. I > do run the risk that I won't get out of the next speeding ticket since > she didn't contribute to the Police Benevolence Association. This depends a lot on how these responses get used. There is a significant difference between using this to get a statistical measure from the population as a whole, and building a personal black-list. I was thinking it might be used for both. What if the call to me was from my colleague's abusive spouse? I may still have a need to receive calls from that person even though my colleague does not. And I don't know if we can assume a forwardee will know that the incoming call has been forwarded. Thanks, Paul > ------------------------------------------------------------------------ > *From:* dispatch on behalf of Paul Kyzivat > > *Sent:* Friday, October 7, 2016 4:18:09 PM > *To:* dispatch@ietf.org > *Subject:* Re: [dispatch] Two new VoIP spam drafts > > On 10/7/16 10:18 AM, Dale R. Worley wrote: >> Henning Schulzrinne writes: >> >>> The whole point of the "Unwanted" response is >>> exactly that the UAC is making a decision on behalf of the destination >>> number and all associated destinations (UACs). >> >> OTOH, my point is that the 6xx response applies to all forks of the >> called number, which may not be the destination number. In fact, the >> called UA doesn't *know* the called number. > > An interesting point. If my calls are forwarded to a colleague while I > am on vacation, and he rejects a caller, does that get handled as *my* > preference? > > If the spam filtering is handled by the same intermediary as the one > handling the forwarding then presumably it can be sorted out. But if the > filtering is done upstream from where the forwarding is done it may be > difficult to tell. > > Thanks, > Paul > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --_000_CY1PR09MB06348537268EBB7DAE80F59CEAC60CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

If you don't want your colleague to spam-mark your calls, you may want t= o tell her. Also, as a local implementation choice, the receiving UA may di= sable the "spam" button if the call (To) is not originally for th= at destination.


Note that the same model works for email, and the world has lived. If I = forward my email to a colleague, the spam button she uses may well trigger = the same (local and/or crowd-sourced) blacklisting.


Users seem to understand spam buttons, recognizing that they occasionall= y lead to mistaken markings and some manual clean-up, such as the postmaste= r whitelisting or removing blacklisted addresses.


I suspect there's only so much we can do for user-facing behavior. We se= em to agree that documenting these cases so that developers can make situat= ionally-appropriate choices seems like a good idea.

From: Paul Kyzivat <pk= yzivat@alum.mit.edu>
Sent: Friday, October 7, 2016 4:52:36 PM
To: Henning Schulzrinne; dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts
 
On 10/7/16 4:31 PM, Henning Schulzrinne wrote:
> I would argue that, practically speaking, there's not much difference.=
> This is a statistical indicator, so whether this truly speaks for the<= br> > principal or his/her vacation sub seems only important at the margins.=
> You could also argue that if you don't trust your colleague to recogni= ze
> spam calls, you may not want him or her to answer calls for you. You m= ay
> even answer one of the "industry thought leader" survey call= s for that
> person...
>
>
> Things get slightly trickier if 666 triggers addition to a personal > blacklist. Even here, I'd argue that this makes sense. If my colleague=
> is kind enough to answer my calls for the next two weeks, she has ever= y
> right not to be bothered by the same nuisance caller multiple times. I=
> do run the risk that I won't get out of the next speeding ticket since=
> she didn't contribute to the Police Benevolence Association.

This depends a lot on how these responses get used. There is a
significant difference between using this to get a statistical measure
from the population as a whole, and building a personal black-list. I
was thinking it might be used for both.

What if the call to me was from my colleague's abusive spouse? I may
still have a need to receive calls from that person even though my
colleague does not.

And I don't know if we can assume a forwardee will know that the
incoming call has been forwarded.

        Thanks,
        Paul

> ----------------------------------------------------------------------= --
> *From:* dispatch <dispatch-bounces@ietf.org> on behalf of Paul K= yzivat
> <pkyzivat@alum.mit.edu>
> *Sent:* Friday, October 7, 2016 4:18:09 PM
> *To:* dispatch@ietf.org
> *Subject:* Re: [dispatch] Two new VoIP spam drafts
>
> On 10/7/16 10:18 AM, Dale R. Worley wrote:
>> Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> writes: >>
>>> The whole point of the "Unwanted" response is
>>> exactly that the UAC is making a decision on behalf of the des= tination
>>> number and all associated destinations (UACs).
>>
>> OTOH, my point is that the 6xx response applies to all forks of th= e
>> called number, which may not be the destination number.  In f= act, the
>> called UA doesn't *know* the called number.
>
> An interesting point. If my calls are forwarded to a colleague while I=
> am on vacation, and he rejects a caller, does that get handled as *my*=
> preference?
>
> If the spam filtering is handled by the same intermediary as the one > handling the forwarding then presumably it can be sorted out. But if t= he
> filtering is done upstream from where the forwarding is done it may be=
> difficult to tell.
>
>         Thanks,
>         Paul
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch
>


 --_000_CY1PR09MB06348537268EBB7DAE80F59CEAC60CY1PR09MB0634namp_-- From nobody Fri Oct 7 14:10:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A809129620 for ; Fri, 7 Oct 2016 14:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 KNC527eVq-20 for ; Fri, 7 Oct 2016 14:10:52 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 831A612943E for ; Fri, 7 Oct 2016 14:10:52 -0700 (PDT) Received: (qmail 9164 invoked by uid 0); 7 Oct 2016 21:10:47 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy5.mail.unifiedlayer.com with SMTP; 7 Oct 2016 21:10:47 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id sl4A1t00K1MNPNq01l4Dt1; Fri, 07 Oct 2016 15:04:13 -0600 X-Authority-Analysis: v=2.1 cv=beT4Do/B c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=1Z4slDfhAAAA:8 a=PYnjg3YJAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=scBmumm3AAAA:8 a=8sgsRP8_f6lNTe8Q9YMA:9 a=qkeApHTGlxzhX1Q5:21 a=VUArjLwTPO26xGpG:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=_Fszbdv8evYA:10 a=JwPPQSbBbIoe0w3YtMrH:22 a=96-UuAdfYG6OSYlHWuPe:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=ef56qr_8hkesV0SKvPxj:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=UfLEb6TuO/tbLUa7kJPI+SaTalZYdCMvQ0n6roxZowY=; b=GQsSBGpbBzMmwkJBPCkMUJd6J4 BgSi5mITLjfwORxSUHwTvnLINJqBy9EgWroL/r89iEmrHpdNnpK7pX3xY7TBat9ytxlzLtC/lWfMc yb7nSimacSOTRro853zHuUvU8; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:51630 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bscJP-0007Jc-V9; Fri, 07 Oct 2016 15:04:12 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 17:04:10 -0400 From: Richard Shockey To: Paul Kyzivat , Michael Hammer , "dispatch@ietf.org" Message-ID: <4DF7FE72-1695-40B3-9B50-2D5CE41F7BA9@shockey.us> Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BD03E98A@sc9-ex2k10mb1.corp.yaanatech.com> <4C7ACBE9-A679-4EDF-8963-EA6F7964DEFC@shockey.us> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bscJP-0007Jc-V9 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:51630 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 21:10:55 -0000 On 10/7/16 3:18 PM, Richard Shockey wrote: > > Right .. and if you want to see some preliminary thinking on what a U= I might look like you can look at this. > > http://www.nanc-chair.org/docs/mtg_docs/Sep16_Robocall_Spoofing_Conce= pts.pdf > > I can assure you that there is a whole mob starting to zero in on the= UI issue. > > Trending Film at 11. > > We need the protocol element. The STIR/SHAKEN construct is useless w= ithout consumer signaling. Some of us have been kicking around similar idea= s in the back channel for months. =20 I agree - one is needed. The problem will arise if the meaning implied=20 by the UI is different from the meaning specified for the response code= .=20 Most people don't read a user guide, much less an RFC, to learn the=20 meaning of a UI element. They intuit the meaning, or have it informally= =20 explained to them by somebody. So the intuitive meaning had better alig= n=20 with the response code. That may mean we have to define the code point=20 while waffling on its precise semantics. RS> I totally understand but we are not the protocol police much less the = UI police. If we define the response code precisely then we simply have to = trust the UE to respond correctly. Plus some of the current thinking is Val= idated might be could be commonly represented within the industry as a green= check but I=E2=80=99m willing to grant the carriers and the PBX vendors some slac= k on how they might add some value here. This debate is going on right now. = What could be industry wide consented in the UE Display vs value add. That said this had better be damn simple and we can=E2=80=99t try and solve every= corner case in the initial deployments. That is my argument on rings of de= fense.=20 The problem with spoofing and robocalls is that the totality of the problem= has made consumers feel helpless and that is not a good thing. I ran across= this recently and it is totally appropriate to this context. =20 https://www.nist.gov/news-events/news/2016/10/security-fatigue-can-cause-co= mputer-users-feel-hopeless-and-act-recklessly I=E2=80=99d really like to hear your views on how to rapidly move this concept al= ong. The IETF does not have a particularly good track record recently on sw= ift and decisive action. What I can testify to (and recently have) is there= is commitment to deploy and a rather unique alignment of industry and regul= atory objectives.=20 =20 Thanks, Paul =20 > I totally support adoption of Henning=E2=80=99s drafts. Hopefully there is= consensus that we don=E2=80=99t need a new WG for this. I do NOT support a new W= G. The need is so critical and the potential for immediate adoption is so g= reat we need to move this along perhaps in some other way. > > Personally I=E2=80=99m totally in favor of 666. I thought that might work = for a proposed Psuedo-ANI code for identifying international call gateways. > > > =E2=80=94 > Richard Shockey > > Shockey Consulting LLC > > Chairman of the Board SIP Forum > > www.shockey.us > > www.sipforum.org > > richardshockey.us > > Skype-Linkedin-Facebook rshockey101 > > PSTN +1 703-593-2683 > > > > On 10/7/16, 11:33 AM, "dispatch on behalf of Michael Hammer" wrote: > > Paul, > > Understand. But, this is chicken or egg issue. > An app developer can't do the UI without the protocol element to = make it > useful. > > Agree with thought that a single "spam" button may be enough of a= n > indicator. > Operator would have to decide at what statistical level to start = tagging new > calls with "possible spam" label. > > ________________________________ > Michael Hammer > michael.hammer@yaanatech.com > +1 408 202 9291 > > =C2=A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email confi= dentiality > notice. This message is private and confidential. If you have rec= eived this > message in error, please notify us and remove it from your system= . > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat > Sent: Thursday, October 06, 2016 2:34 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam dra= fts) > > On 10/6/16 1:48 PM, Michael Hammer wrote: > > I like the idea of a unique non-overloaded code point that > > > > can be used to drive some peg-counts or big data analysis of ca= lls > > > > to highlight the numbers and rates in real-time, so that > > > > systems could proactively tag next calls to say to called user > > > > that this next call had 100,000 users saying it was a robo-call= . > > This would be nice. But it depends on more than a unique response= code. > It also needs for users to only use that code for the semantic yo= u want to > tag it with. This depends as much on the UI provided to users as = it does on > the existence of the code(s). > > Of necessity the UI will be simple, with few choices for how to r= eject a > call. (I guess one or possibly two.) Those can then be mapped to = particular > response codes. But it will be hard to get users to use those but= tons for > precisely the semantics we want to ascribe to the codes. (Do we w= e want the > button to mean "unwanted robo-call", "call from undesired caller"= , > "objectionable call content", or what?) > > Even though the IETF doesn't "do" UIs, it might be better to disc= uss the > likely UI before fully defining the code(s). > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > =20 =20 From nobody Fri Oct 7 14:41:55 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE6A12946A for ; Fri, 7 Oct 2016 14:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 G4lpVa-iY656 for ; Fri, 7 Oct 2016 14:41:50 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 4051B129417 for ; Fri, 7 Oct 2016 14:41:50 -0700 (PDT) Received: (qmail 28743 invoked by uid 0); 7 Oct 2016 21:41:49 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 7 Oct 2016 21:41:49 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id slck1t00T1MNPNq01lcnrq; Fri, 07 Oct 2016 15:36:49 -0600 X-Authority-Analysis: v=2.1 cv=IecUBwaa c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=CH0kA5CcgfcA:10 a=ZZnuYtJkoWoA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=sXioG8C6ll3R3jXc_JwA:9 a=9WbDPNoOJSTBMYOd:21 a=Yrwa6UAO0ISM4evo:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=2Xex6C3OkOzxELCl4dsA:9 a=I6Z9Sy5hSDJoolxH:21 a=r9AVI4Jdm4BWakKV:21 a=Fxy5SKsFvojYfRLx:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date; bh=pTh+scjbdatbvpHJQThzPBBgD4aFUNJbyWl1Kp0u11U=; b=KfBTOdD T0eRa7yo1vNFZfw6bBrncUMQjJ2+teb+NM5/nMmHIlwL3oDZ+vr9xFTbOOWSrCxxaDwG4cTORjPFH vJp4goi3Lq35/ikKq4mnFcHWX4t8Kz1vaVS4m9kEioGM; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:51764 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bscou-0005dq-Bh; Fri, 07 Oct 2016 15:36:44 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 07 Oct 2016 17:36:42 -0400 From: Richard Shockey To: Henning Schulzrinne , Paul Kyzivat , "dispatch@ietf.org" Message-ID: <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> Thread-Topic: [dispatch] Two new VoIP spam drafts References: <87y4205jkr.fsf@hobgoblin.ariadne.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3558706604_234463402" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bscou-0005dq-Bh X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:51764 X-Source-Auth: richard+shockey.us X-Email-Count: 5 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 21:41:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3558706604_234463402 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable +1 =20 Though I have endless issues with blacklisting for endless reasons.=C2=A0 You c= an blacklist =E2=80=A6 but then how do you get off the black list if you have reas= on to believe you improperly put on in the first place. That has been the ba= ne of SPAMHOUS and the rest of those from the beginning = which is why I=E2=80=99ve totally opposed trying to simply say =E2=80=9Cwell we solved t= his in DANE or DKIM so problem solved.=E2=80=9D=C2=A0 This is telephony not email.=20 =20 As a general principal Henning is right ..there is only so much we can do. = We can anticipate specific use cases but until we get some reasonable operat= ional experience we can=E2=80=99t refine the process. =C2=A0=C2=A0=C2=A0 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 =20 From: dispatch on behalf of Henning Schulzrinne= Date: Friday, October 7, 2016 at 5:05 PM To: Paul Kyzivat , "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts =20 If you don't want your colleague to spam-mark your calls, you may want to t= ell her. Also, as a local implementation choice, the receiving UA may disabl= e the "spam" button if the call (To) is not originally for that destination. =20 Note that the same model works for email, and the world has lived. If I for= ward my email to a colleague, the spam button she uses may well trigger the = same (local and/or crowd-sourced) blacklisting. =20 Users seem to understand spam buttons, recognizing that they occasionally l= ead to mistaken markings and some manual clean-up, such as the postmaster wh= itelisting or removing blacklisted addresses. =20 I suspect there's only so much we can do for user-facing behavior. We seem = to agree that documenting these cases so that developers can make situationa= lly-appropriate choices seems like a good idea. From: Paul Kyzivat Sent: Friday, October 7, 2016 4:52:36 PM To: Henning Schulzrinne; dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts=20 =20 On 10/7/16 4:31 PM, Henning Schulzrinne wrote: > I would argue that, practically speaking, there's not much difference. > This is a statistical indicator, so whether this truly speaks for the > principal or his/her vacation sub seems only important at the margins. > You could also argue that if you don't trust your colleague to recognize > spam calls, you may not want him or her to answer calls for you. You may > even answer one of the "industry thought leader" survey calls for that > person... > > > Things get slightly trickier if 666 triggers addition to a personal > blacklist. Even here, I'd argue that this makes sense. If my colleague > is kind enough to answer my calls for the next two weeks, she has every > right not to be bothered by the same nuisance caller multiple times. I > do run the risk that I won't get out of the next speeding ticket since > she didn't contribute to the Police Benevolence Association. This depends a lot on how these responses get used. There is a=20 significant difference between using this to get a statistical measure=20 from the population as a whole, and building a personal black-list. I=20 was thinking it might be used for both. What if the call to me was from my colleague's abusive spouse? I may=20 still have a need to receive calls from that person even though my=20 colleague does not. And I don't know if we can assume a forwardee will know that the=20 incoming call has been forwarded. Thanks, Paul > ------------------------------------------------------------------------ > *From:* dispatch on behalf of Paul Kyzivat > > *Sent:* Friday, October 7, 2016 4:18:09 PM > *To:* dispatch@ietf.org > *Subject:* Re: [dispatch] Two new VoIP spam drafts > > On 10/7/16 10:18 AM, Dale R. Worley wrote: >> Henning Schulzrinne writes: >> >>> The whole point of the "Unwanted" response is >>> exactly that the UAC is making a decision on behalf of the destination >>> number and all associated destinations (UACs). >> >> OTOH, my point is that the 6xx response applies to all forks of the >> called number, which may not be the destination number. In fact, the >> called UA doesn't *know* the called number. > > An interesting point. If my calls are forwarded to a colleague while I > am on vacation, and he rejects a caller, does that get handled as *my* > preference? > > If the spam filtering is handled by the same intermediary as the one > handling the forwarding then presumably it can be sorted out. But if the > filtering is done upstream from where the forwarding is done it may be > difficult to tell. > > Thanks, > Paul > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispa= tch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch=20 --B_3558706604_234463402 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

+1

 

Though I have endless= issues with blacklisting for endless reasons.=C2=A0 You can blacklist … b= ut then how do you get off the black list if you have reason to believe you = improperly put on in the first place. That has been the bane of SPAMHOUS and= the rest of those <fill in the blank> from the beginning which is why= I’ve totally opposed trying to simply say “well we solved this = in DANE or DKIM so problem solved.”=C2=A0 This is telephony not email.

 

As a general principal Henning is right .= .there is only so much we can do. We can anticipate specific use cases but u= ntil we get some reasonable operational experience we can’t refine the= process. =C2=A0=C2=A0=C2=A0

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP= Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Lin= kedin-Facebook rshockey101

PSTN +1 703-593-2683

<= /div>

<= o:p> 

 

From: dispatch <dispatch-bounces@ietf.org>= on behalf of Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
= Date: Friday, October 7, 2016 at 5:05 PM
To: Paul Kyzivat <= pkyzivat@alum.mit.edu>, "dispatch@ietf.org" <dispatch@ietf.o= rg>
Subject: Re: [dispatch] Two new VoIP spam drafts=

 

If you don't want your colleague to spam-mark your calls, you may want to= tell her. Also, as a local implementation choice, the receiving UA may disa= ble the "spam" button if the call (To) is not originally for that = destination.

 

Note that the same model works for email, and the world has lived. I= f I forward my email to a colleague, the spam button she uses may well trigg= er the same (local and/or crowd-sourced) blacklisting.

=

 

Users seem to understand s= pam buttons, recognizing that they occasionally lead to mistaken markings an= d some manual clean-up, such as the postmaster whitelisting or removing blac= klisted addresses.

 

I suspect there's only so much we can do for user-facing behav= ior. We seem to agree that documenting these cases so that developers can ma= ke situationally-appropriate choices seems like a good idea.

Fro= m:= Paul Kyzivat <pkyzivat@alum.mit.edu>
Sent: Friday, October = 7, 2016 4:52:36 PM
To: Henning Schulzrinne; dispatch@ietf.org
<= b>Subject: Re: [dispatch] Two new VoIP spam drafts

 

On 1= 0/7/16 4:31 PM, Henning Schulzrinne wrote:
> I would argue that, pract= ically speaking, there's not much difference.
> This is a statistical = indicator, so whether this truly speaks for the
> principal or his/her= vacation sub seems only important at the margins.
> You could also ar= gue that if you don't trust your colleague to recognize
> spam calls, = you may not want him or her to answer calls for you. You may
> even an= swer one of the "industry thought leader" survey calls for that> person...
>
>
> Things get slightly trickier if 666 = triggers addition to a personal
> blacklist. Even here, I'd argue that= this makes sense. If my colleague
> is kind enough to answer my calls= for the next two weeks, she has every
> right not to be bothered by t= he same nuisance caller multiple times. I
> do run the risk that I won= 't get out of the next speeding ticket since
> she didn't contribute t= o the Police Benevolence Association.

This depends a lot on how these= responses get used. There is a
significant difference between using thi= s to get a statistical measure
from the population as a whole, and build= ing a personal black-list. I
was thinking it might be used for both.
=
What if the call to me was from my colleague's abusive spouse? I may still have a need to receive calls from that person even though my
coll= eague does not.

And I don't know if we can assume a forwardee will kn= ow that the
incoming call has been forwarded.

   &= nbsp;    Thanks,
       = ; Paul

> ---------------------------------------------------------= ---------------
> *From:* dispatch <dispatch-bounces@ietf.org> o= n behalf of Paul Kyzivat
> <pkyzivat@alum.mit.edu>
> *Sent= :* Friday, October 7, 2016 4:18:09 PM
> *To:* dispatch@ietf.org
>= ; *Subject:* Re: [dispatch] Two new VoIP spam drafts
>
> On 10/7= /16 10:18 AM, Dale R. Worley wrote:
>> Henning Schulzrinne <Henn= ing.Schulzrinne@fcc.gov> writes:
>>
>>> The whole po= int of the "Unwanted" response is
>>> exactly that the= UAC is making a decision on behalf of the destination
>>> numbe= r and all associated destinations (UACs).
>>
>> OTOH, my p= oint is that the 6xx response applies to all forks of the
>> called= number, which may not be the destination number.  In fact, the
>= > called UA doesn't *know* the called number.
>
> An interest= ing point. If my calls are forwarded to a colleague while I
> am on va= cation, and he rejects a caller, does that get handled as *my*
> prefe= rence?
>
> If the spam filtering is handled by the same intermed= iary as the one
> handling the forwarding then presumably it can be so= rted out. But if the
> filtering is done upstream from where the forwa= rding is done it may be
> difficult to tell.
>
> &nbs= p;       Thanks,
>   &nbs= p;     Paul
>
>
>
> ____________= ___________________________________
> dispatch mailing list
> di= spatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

=

__________________________________= _____________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/m= ailman/listinfo/dispatch

--B_3558706604_234463402-- From nobody Sat Oct 8 09:17:47 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035E7129518 for ; Sat, 8 Oct 2016 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 j8bx4pTWUXBp for ; Sat, 8 Oct 2016 09:17:43 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A974129471 for ; Sat, 8 Oct 2016 09:17:42 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-03v.sys.comcast.net with SMTP id suJhbr4ep8GkCsuJhbsgLN; Sat, 08 Oct 2016 16:17:41 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-06v.sys.comcast.net with SMTP id suJgbQKAF97PRsuJhblSHR; Sat, 08 Oct 2016 16:17:41 +0000 To: Richard Shockey , Henning Schulzrinne , "dispatch@ietf.org" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> From: Paul Kyzivat Message-ID: Date: Sat, 8 Oct 2016 12:17:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDL0I/khs+gzZc40nUrAn789f9N4LGHxYojaU2/uBbjiLCKlBaTxn2SXc9TPEP0UKf8fb8/RihObq4pAwyrw/i6E3hJF8gOVXchhLtGNRmq0m6LYBgZK OnqvzQeWWxwluQyt855GwyNVY0vGIeI3JZA2bT9VAb9BW59r790Oq7a66PKsG69MDTY8CMoKYAcqqzPllDsDAWhoPBCvPj2TwSxaHi7D0TqEH+Uin07NGZSY edDvM/zmjhHRyqOUQWnl+g== Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 16:17:46 -0000 On 10/7/16 5:36 PM, Richard Shockey wrote: > +1 > > > > Though I have endless issues with blacklisting for endless reasons. You > can blacklist … but then how do you get off the black list if you have > reason to believe you improperly put on in the first place. That has > been the bane of SPAMHOUS and the rest of those from > the beginning which is why I’ve totally opposed trying to simply say > “well we solved this in DANE or DKIM so problem solved.” This is > telephony not email. > > > > As a general principal Henning is right ..there is only so much we can > do. We can anticipate specific use cases but until we get some > reasonable operational experience we can’t refine the process. I agree with all of that. But it says we are defining a code without defining precisely what it means - that we are leaving it to the implementations and UI designers to decide what it means. So the definition of the meaning of the code should be correspondingly vague. Thanks, Paul > — > > Richard Shockey > > Shockey Consulting LLC > > Chairman of the Board SIP Forum > > www.shockey.us > > www.sipforum.org > > richardshockey.us > > Skype-Linkedin-Facebook rshockey101 > > PSTN +1 703-593-2683 > > > > > > *From: *dispatch on behalf of Henning > Schulzrinne > *Date: *Friday, October 7, 2016 at 5:05 PM > *To: *Paul Kyzivat , "dispatch@ietf.org" > > *Subject: *Re: [dispatch] Two new VoIP spam drafts > > > > If you don't want your colleague to spam-mark your calls, you may want > to tell her. Also, as a local implementation choice, the receiving UA > may disable the "spam" button if the call (To) is not originally for > that destination. > > > > Note that the same model works for email, and the world has lived. If I > forward my email to a colleague, the spam button she uses may well > trigger the same (local and/or crowd-sourced) blacklisting. > > > > Users seem to understand spam buttons, recognizing that they > occasionally lead to mistaken markings and some manual clean-up, such as > the postmaster whitelisting or removing blacklisted addresses. > > > > I suspect there's only so much we can do for user-facing behavior. We > seem to agree that documenting these cases so that developers can make > situationally-appropriate choices seems like a good idea. > > ------------------------------------------------------------------------ > > *From:*Paul Kyzivat > *Sent:* Friday, October 7, 2016 4:52:36 PM > *To:* Henning Schulzrinne; dispatch@ietf.org > *Subject:* Re: [dispatch] Two new VoIP spam drafts > > > > On 10/7/16 4:31 PM, Henning Schulzrinne wrote: >> I would argue that, practically speaking, there's not much difference. >> This is a statistical indicator, so whether this truly speaks for the >> principal or his/her vacation sub seems only important at the margins. >> You could also argue that if you don't trust your colleague to recognize >> spam calls, you may not want him or her to answer calls for you. You may >> even answer one of the "industry thought leader" survey calls for that >> person... >> >> >> Things get slightly trickier if 666 triggers addition to a personal >> blacklist. Even here, I'd argue that this makes sense. If my colleague >> is kind enough to answer my calls for the next two weeks, she has every >> right not to be bothered by the same nuisance caller multiple times. I >> do run the risk that I won't get out of the next speeding ticket since >> she didn't contribute to the Police Benevolence Association. > > This depends a lot on how these responses get used. There is a > significant difference between using this to get a statistical measure > from the population as a whole, and building a personal black-list. I > was thinking it might be used for both. > > What if the call to me was from my colleague's abusive spouse? I may > still have a need to receive calls from that person even though my > colleague does not. > > And I don't know if we can assume a forwardee will know that the > incoming call has been forwarded. > > Thanks, > Paul > >> ------------------------------------------------------------------------ >> *From:* dispatch on behalf of Paul Kyzivat >> >> *Sent:* Friday, October 7, 2016 4:18:09 PM >> *To:* dispatch@ietf.org >> *Subject:* Re: [dispatch] Two new VoIP spam drafts >> >> On 10/7/16 10:18 AM, Dale R. Worley wrote: >>> Henning Schulzrinne writes: >>> >>>> The whole point of the "Unwanted" response is >>>> exactly that the UAC is making a decision on behalf of the destination >>>> number and all associated destinations (UACs). >>> >>> OTOH, my point is that the 6xx response applies to all forks of the >>> called number, which may not be the destination number. In fact, the >>> called UA doesn't *know* the called number. >> >> An interesting point. If my calls are forwarded to a colleague while I >> am on vacation, and he rejects a caller, does that get handled as *my* >> preference? >> >> If the spam filtering is handled by the same intermediary as the one >> handling the forwarding then presumably it can be sorted out. But if the >> filtering is done upstream from where the forwarding is done it may be >> difficult to tell. >> >> Thanks, >> Paul >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ dispatch mailing list > dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch > From nobody Sat Oct 8 09:33:23 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193CF1294FD for ; Sat, 8 Oct 2016 09:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 quQhAZGSMEds for ; Sat, 8 Oct 2016 09:33:19 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710881288B8 for ; Sat, 8 Oct 2016 09:33:19 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u98GPluV038603; Sat, 8 Oct 2016 12:33:15 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 25xvryrm3s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Oct 2016 12:33:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u98GXDI8020132; Sat, 8 Oct 2016 12:33:13 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u98GX4Gc020065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Oct 2016 12:33:05 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sat, 8 Oct 2016 16:32:52 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.250]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0301.000; Sat, 8 Oct 2016 12:32:51 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWi2HwzrKjG+EiQ+j755/EMs6CdsZqAgAADqYCAAAX3AIAAA4wAgAAIxgCAATkyAP//wS9G Date: Sat, 8 Oct 2016 16:32:50 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C0D0A73C9A1F4FB6BE08831D1AF79E5Aattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610080288 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 16:33:22 -0000 --_000_C0D0A73C9A1F4FB6BE08831D1AF79E5Aattcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Not so. SP records code and initiates procedures (reporting, blacklist, tra= ce back) Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 8, 2016, at 12:17 PM, Paul Kyzivat > wrote: On 10/7/16 5:36 PM, Richard Shockey wrote: +1 Though I have endless issues with blacklisting for endless reasons. You can blacklist =85 but then how do you get off the black list if you have reason to believe you improperly put on in the first place. That has been the bane of SPAMHOUS and the rest of those from the beginning which is why I=92ve totally opposed trying to simply say =93well we solved this in DANE or DKIM so problem solved.=94 This is telephony not email. As a general principal Henning is right ..there is only so much we can do. We can anticipate specific use cases but until we get some reasonable operational experience we can=92t refine the process. I agree with all of that. But it says we are defining a code without defini= ng precisely what it means - that we are leaving it to the implementations = and UI designers to decide what it means. So the definition of the meaning = of the code should be correspondingly vague. Thanks, Paul =97 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 *From: *dispatch > on behalf of Henning Schulzrinne > *Date: *Friday, October 7, 2016 at 5:05 PM *To: *Paul Kyzivat >, "= dispatch@ietf.org" > *Subject: *Re: [dispatch] Two new VoIP spam drafts If you don't want your colleague to spam-mark your calls, you may want to tell her. Also, as a local implementation choice, the receiving UA may disable the "spam" button if the call (To) is not originally for that destination. Note that the same model works for email, and the world has lived. If I forward my email to a colleague, the spam button she uses may well trigger the same (local and/or crowd-sourced) blacklisting. Users seem to understand spam buttons, recognizing that they occasionally lead to mistaken markings and some manual clean-up, such as the postmaster whitelisting or removing blacklisted addresses. I suspect there's only so much we can do for user-facing behavior. We seem to agree that documenting these cases so that developers can make situationally-appropriate choices seems like a good idea. ------------------------------------------------------------------------ *From:*Paul Kyzivat > *Sent:* Friday, October 7, 2016 4:52:36 PM *To:* Henning Schulzrinne; dispatch@ietf.org *Subject:* Re: [dispatch] Two new VoIP spam drafts On 10/7/16 4:31 PM, Henning Schulzrinne wrote: I would argue that, practically speaking, there's not much difference. This is a statistical indicator, so whether this truly speaks for the principal or his/her vacation sub seems only important at the margins. You could also argue that if you don't trust your colleague to recognize spam calls, you may not want him or her to answer calls for you. You may even answer one of the "industry thought leader" survey calls for that person... Things get slightly trickier if 666 triggers addition to a personal blacklist. Even here, I'd argue that this makes sense. If my colleague is kind enough to answer my calls for the next two weeks, she has every right not to be bothered by the same nuisance caller multiple times. I do run the risk that I won't get out of the next speeding ticket since she didn't contribute to the Police Benevolence Association. This depends a lot on how these responses get used. There is a significant difference between using this to get a statistical measure from the population as a whole, and building a personal black-list. I was thinking it might be used for both. What if the call to me was from my colleague's abusive spouse? I may still have a need to receive calls from that person even though my colleague does not. And I don't know if we can assume a forwardee will know that the incoming call has been forwarded. Thanks, Paul ------------------------------------------------------------------------ *From:* dispatch > on behalf of Paul Kyzivat > *Sent:* Friday, October 7, 2016 4:18:09 PM *To:* dispatch@ietf.org *Subject:* Re: [dispatch] Two new VoIP spam drafts On 10/7/16 10:18 AM, Dale R. Worley wrote: Henning Schulzrinne > writes: The whole point of the "Unwanted" response is exactly that the UAC is making a decision on behalf of the destination number and all associated destinations (UACs). OTOH, my point is that the 6xx response applies to all forks of the called number, which may not be the destination number. In fact, the called UA doesn't *know* the called number. An interesting point. If my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, does that get handled as *my* preference? If the spam filtering is handled by the same intermediary as the one handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be difficult to tell. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/li= stinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C0D0A73C9A1F4FB6BE08831D1AF79E5Aattcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Not so. SP records code and initiates procedures (reporting, blacklist= , trace back)

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Oct 8, 2016, at 12:17 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 10/7/16 5:36 PM, Richard Shockey wrote:
+1



Though I have endless issues with blacklist= ing for endless reasons.  You
can blacklist =85 but then how do you get o= ff the black list if you have
reason to believe you improperly put on in = the first place. That has
been the bane of SPAMHOUS and the rest of t= hose <fill in the blank> from
the beginning which is why I=92ve totally o= pposed trying to simply say
=93well we solved this in DANE or DKIM so p= roblem solved.=94  This is
telephony not email.



As a general principal Henning is right ..t= here is only so much we can
do. We can anticipate specific use cases bu= t until we get some
reasonable operational experience we can=92= t refine the process.

I agree with all of that. But it says we are defining a code without = defining precisely what it means - that we are leaving it to the implementa= tions and UI designers to decide what it means. So the definition of the me= aning of the code should be correspondingly vague.

   Thanks,
   Paul

=97

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shock= ey.us

www.sip= forum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101<= br>

PSTN +1 703-593-2683





*From: *dispatch <dispatch-bounces@ietf.org> on behalf of Henni= ng
Schulzrinne <Henning.Schulzrinne@fcc.gov>
*Date: *Friday, October 7, 2016 at 5:05 PM<= /span>
*To: *Paul Kyzivat <pkyzivat@alum.mit.edu>, "dispatch@ietf.org"
<di= spatch@ietf.org>
*Subject: *Re: [dispatch] Two new VoIP spam= drafts



If you don't want your colleague to spam-ma= rk your calls, you may want
to tell her. Also, as a local implementatio= n choice, the receiving UA
may disable the "spam" button if = the call (To) is not originally for
that destination.



Note that the same model works for email, a= nd the world has lived. If I
forward my email to a colleague, the spam b= utton she uses may well
trigger the same (local and/or crowd-source= d) blacklisting.



Users seem to understand spam buttons, reco= gnizing that they
occasionally lead to mistaken markings and = some manual clean-up, such as
the postmaster whitelisting or removing bla= cklisted addresses.



I suspect there's only so much we can do fo= r user-facing behavior. We
seem to agree that documenting these cases = so that developers can make
situationally-appropriate choices seems lik= e a good idea.

-------------------------------------------= -----------------------------

*From:*Paul Kyzivat <pkyzivat@alum.mit.edu>
*Sent:* Friday, October 7, 2016 4:52:36 PM<= /span>
*To:* Henning Schulzrinne; dispatch@ietf.org
*Subject:* Re: [dispatch] Two new VoIP spam= drafts



On 10/7/16 4:31 PM, Henning Schulzrinne wro= te:
I would argue that, practically speaking, t= here's not much difference.
This is a statistical indicator, so whether= this truly speaks for the
principal or his/her vacation sub seems onl= y important at the margins.
You could also argue that if you don't trus= t your colleague to recognize
spam calls, you may not want him or her to = answer calls for you. You may
even answer one of the "industry thoug= ht leader" survey calls for that
person...


Things get slightly trickier if 666 trigger= s addition to a personal
blacklist. Even here, I'd argue that this m= akes sense. If my colleague
is kind enough to answer my calls for the n= ext two weeks, she has every
right not to be bothered by the same nuisan= ce caller multiple times. I
do run the risk that I won't get out of the= next speeding ticket since
she didn't contribute to the Police Benevol= ence Association.

This depends a lot on how these responses g= et used. There is a
significant difference between using this t= o get a statistical measure
from the population as a whole, and buildin= g a personal black-list. I
was thinking it might be used for both.

What if the call to me was from my colleagu= e's abusive spouse? I may
still have a need to receive calls from tha= t person even though my
colleague does not.

And I don't know if we can assume a forward= ee will know that the
incoming call has been forwarded.

       T= hanks,
       P= aul

-------------------------------------------= -----------------------------
*From:* dispatch <dispatch-bounces@ietf.org> on behalf of Paul = Kyzivat
<pkyzivat@alum.mit.edu>
*Sent:* Friday, October 7, 2016 4:18:09 PM<= /span>
*To:* = dispatch@ietf.org
*Subject:* Re: [dispatch] Two new VoIP spam= drafts

On 10/7/16 10:18 AM, Dale R. Worley wrote:<= /span>
Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> writes:

The whole point of the "Unwanted"= response is
exactly that the UAC is making a decision o= n behalf of the destination
number and all associated destinations (UAC= s).

OTOH, my point is that the 6xx response app= lies to all forks of the
called number, which may not be the destina= tion number.  In fact, the
called UA doesn't *know* the called number.=

An interesting point. If my calls are forwa= rded to a colleague while I
am on vacation, and he rejects a caller, do= es that get handled as *my*
preference?

If the spam filtering is handled by the sam= e intermediary as the one
handling the forwarding then presumably it = can be sorted out. But if the
filtering is done upstream from where the f= orwarding is done it may be
difficult to tell.

       T= hanks,
       P= aul



___________________________________________= ____
dispatch mailing list
dispat= ch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


___________________________________________= ____ dispatch mailing list
dispat= ch@ietf.org https://www.ietf= .org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_C0D0A73C9A1F4FB6BE08831D1AF79E5Aattcom_-- From nobody Sat Oct 8 13:21:03 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB32D1293E4 for ; Sat, 8 Oct 2016 13:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 QKkIyncWIoy1 for ; Sat, 8 Oct 2016 13:21:00 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE999120726 for ; Sat, 8 Oct 2016 13:21:00 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-04v.sys.comcast.net with SMTP id sy79bIyAQ8Peasy7AbNRV4; Sat, 08 Oct 2016 20:21:00 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-11v.sys.comcast.net with SMTP id sy79bf8hwK4yLsy79bYUmj; Sat, 08 Oct 2016 20:21:00 +0000 To: "DOLLY, MARTIN C" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> From: Paul Kyzivat Message-ID: Date: Sat, 8 Oct 2016 16:20:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfA+2U/PF3eTBx0T6l10nT0Pv5SwoBnyqrTg8wyailrW2LnleECXhnkNZIy3hY6yfEV7T9iK+sG/IFB2+omi/gRB1sbyGG2PwcN3b8ikjfQDiIbs+HDD6 pPsR60GOcjrFC0rHAkWlSWiYh7WjGW7bmoxt0AcOkYs/KkbCHKD8M7iGKIt0lFgeLU/C0iTIzE/JYfnIE2e5BniN6M/9Jzy/6MWY5E+kSF9Gly+cBpxxXGG2 XKHXvEpSjD6O87XBs175ebuHUOxdT9tDDtqn/++BTI0= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 20:21:02 -0000 On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: > Not so. SP records code and initiates procedures (reporting, blacklist, > trace back) I assume this is intended as a response to: > On Oct 8, 2016, at 12:17 PM, Paul Kyzivat > wrote: >> I agree with all of that. But it says we are defining a code without >> defining precisely what it means - that we are leaving it to the >> implementations and UI designers to decide what it means. So the >> definition of the meaning of the code should be correspondingly vague. When I said *we* I meant the people who will collectively be deciding to approve a new response code. Then there are SPs who will be implementing services in the network based on receiving this code, and device makers who will be designing UI through which users can cause this code to be signaled. It sounds like there may be at least two different services that SPs will implement based on the new code: (1) a statistical determination of generally bad actors, and (2) a private blacklist for individual subscribers. And in addition to SPs, others (e.g. PBX vendors) may also be implementing (2). In addition to the SPs, there may also be others (e.g. PBX vendors) implementing private blacklists, either for their system as a whole or for each of their individual users, based on the same codes. Who, in this collection of participants should define the precise meaning of the code? It would be unfortunate if pressing the same button on the phone means one thing at work, something different on my ATT phone, and something different from that after I port my phone to Verizon. If the intent is that the FCC and the US providers decide the meaning for the US, then the definition should reflect that that is what it is. Thanks, Paul From nobody Sun Oct 9 02:58:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0791293F4 for ; Sun, 9 Oct 2016 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 zjNAUTeMz-os for ; Sun, 9 Oct 2016 02:58:37 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0045.outbound.protection.outlook.com [104.47.36.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFE612946D for ; Sun, 9 Oct 2016 02:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5whK9iBkyLy4NfyUkTf0m/6rUl/SHf8zS5TiqZXa5rU=; b=XPGTr9cFL0PzyR5N6jSxCTFKFpxm/N2vpZV8/5FlGuPHhuqo20BlsbYjTAZ8GavxRDYRfgbg67FVH2paRGfcRN4RU1vSiilL+Wj9XzfYkqByCGLe1soDVdI2u0XadkLc+s358TWs7q8QKGDMxXWTP6WA46CigytZj+p8dxrVopA= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 9 Oct 2016 09:58:35 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0659.018; Sun, 9 Oct 2016 09:58:34 +0000 From: "Asveren, Tolga" To: Richard Shockey , Paul Kyzivat , Michael Hammer , "dispatch@ietf.org" Thread-Topic: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) Thread-Index: AQHSH8RkUGymfmKcfEurqeiaCjjufKCbXw+hgAADTACAAF6UQIABs5LUgAAIqACAAmpmMA== Date: Sun, 9 Oct 2016 09:58:34 +0000 Message-ID: References: <4291475753141@web24g.yandex.ru> <3fe8777f857e2b8be7c652c110c0629d@mail.gmail.com> <00C069FD01E0324C9FFCADF539701DB3BD03E0E9@sc9-ex2k10mb1.corp.yaanatech.com> <4a56b339-af08-720c-15d4-b3e4d4fe9595@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BD03E98A@sc9-ex2k10mb1.corp.yaanatech.com> <4C7ACBE9-A679-4EDF-8963-EA6F7964DEFC@shockey.us> <4DF7FE72-1695-40B3-9B50-2D5CE41F7BA9@shockey.us> In-Reply-To: <4DF7FE72-1695-40B3-9B50-2D5CE41F7BA9@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ff752be5-ecf0-4ab2-547c-08d3f02ad576 x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 6:GNNz+kCx+dsv9UdEDyAmljjAIdIqCMaV29b5Va+OdFaeuN2y/+pB+ibGkz5U6FWIfU/0l3cC7waVsSwOvgCo5EAu5jRz0ub+ucik7vJh9t8ofB2ym5M54hqemDAjoMlFoRY7xeoUNnZ7NqTzqgJuYteTkMVCAg7k3eOov7lQod+1O+E3ufyOQFbj/gW2+IPc/eBvroDfnYEkwD7iTp7QNfNz4a1MYLk4AnlT+pQdY2y/YRGdZuX9rOADDFGEyMY5POLr57wZtyOP8vvE3K+io/0DslmU4grtuWIFuRs2AxE/kZpC4TsCts/d7e2YvVHk; 5:iWLwDAAbjWhvS0edWf6jjvJnpp3EnHBtA9FFy+W2uaau3efWVQhKGxKcTVRp55TiNmI5sK72dP59oV4RuWbN+h0zZwkwctA3OnRHm3n54MUX04TdDeOyKqhcn0uO5HPLfAAMakGgB1qRraDhZBFvKA==; 24:cXNBHmX0lYG1mUw6lWSrzmai4xQHnO3Yr7Mhmawze7ozhtvi5UUoREyybstf6V1Xx6Y9E1eD0rolY6C/HEcCS/ZW1IjC0DingAU389/O1c4=; 7:ARhEidILPKnXQZVTTumgj367KvM6XinYFcfb2Ew4jGz8GBrB8AyypTP5H4y/ygrgTgNxc78nrcMz6GvVRcpVs/2IFED5Yo1RA56JfOxQisWTEKzALR05AY5O5baavW0N1NoBaqN0ZPgczV3u86dgWDPwKHPRtX/GRNGqxX0693LTuaswRmUo8OyrCr3w8tbDTtU/QkdETpA0M4On6MBv58xbe65Q60wiGKufDuyZ4xYdEmf3L7D1HGbnH6p+WxBegBnI4P88kKGe7mfIlb7+CZ78gU1+koMqkT3Mgavp6CSBckYPkRSCGhByfkukl10A x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(100405760836317)(2006787148836); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 00909363D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(13464003)(199003)(377454003)(111735001)(2950100002)(15975445007)(106116001)(2906002)(77096005)(2900100001)(93886004)(5660300001)(7696004)(5002640100001)(92566002)(54356999)(99286002)(66066001)(76176999)(8936002)(105586002)(106356001)(101416001)(50986999)(33656002)(7846002)(15974865002)(305945005)(74316002)(7736002)(81166006)(81156014)(76576001)(189998001)(19580395003)(19580405001)(122556002)(86362001)(10400500002)(3280700002)(586003)(3660700001)(102836003)(68736007)(6116002)(3846002)(5001770100001)(107886002)(97736004)(2171001)(2501003)(8676002)(9686002)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2016 09:58:34.7234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Subject: Re: [dispatch] 4xx vs 6xx (was Re: Two new VoIP spam drafts) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 09:58:44 -0000 Q291bGRu4oCZdCBhZ3JlZSBtb3JlIHdpdGggdGhlICJ0aGlzIGlzIHVyZ2VudGx5IG5lZWRlZCIg c3RhdGVtZW50LiBJIGhvcGUgYWxsIHJlYXNvbmFibGUgY29uY2VybnMgY2FuIGJlIGFkZHJlc3Nl ZCBBU0FQIGFuZCB0aGUgZG9jdW1lbnQgY2FuIG1vdmUgZm9yd2FyZC4NCg0KVGhhbmtzLA0KVG9s Z2ENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkaXNwYXRjaCBbbWFp bHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNoYXJkDQo+IFNo b2NrZXkNCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDA3LCAyMDE2IDU6MDQgUE0NCj4gVG86IFBh dWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgTWljaGFlbCBIYW1tZXINCj4gPG1p Y2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20+OyBkaXNwYXRjaEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW2Rpc3BhdGNoXSA0eHggdnMgNnh4ICh3YXMgUmU6IFR3byBuZXcgVm9JUCBzcGFtIGRy YWZ0cykNCj4gDQo+IA0KPiANCj4gICAgIE9uIDEwLzcvMTYgMzoxOCBQTSwgUmljaGFyZCBTaG9j a2V5IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPiBSaWdodCAuLiBhbmQgaWYgeW91IHdhbnQgdG8g c2VlIHNvbWUgcHJlbGltaW5hcnkgdGhpbmtpbmcgb24gd2hhdCBhIFVJDQo+IG1pZ2h0IGxvb2sg bGlrZSB5b3UgY2FuIGxvb2sgYXQgdGhpcy4NCj4gICAgID4NCj4gICAgID4gaHR0cDovL3d3dy5u YW5jLQ0KPiBjaGFpci5vcmcvZG9jcy9tdGdfZG9jcy9TZXAxNl9Sb2JvY2FsbF9TcG9vZmluZ19D b25jZXB0cy5wZGYNCj4gICAgID4NCj4gICAgID4gSSBjYW4gYXNzdXJlIHlvdSB0aGF0IHRoZXJl IGlzIGEgd2hvbGUgbW9iIHN0YXJ0aW5nIHRvIHplcm8gaW4gb24gdGhlIFVJDQo+IGlzc3VlLg0K PiAgICAgPg0KPiAgICAgPiBUcmVuZGluZyBGaWxtIGF0IDExLg0KPiAgICAgPg0KPiAgICAgPiBX ZSBuZWVkIHRoZSBwcm90b2NvbCBlbGVtZW50LiAgVGhlIFNUSVIvU0hBS0VOIGNvbnN0cnVjdCBp cyB1c2VsZXNzDQo+IHdpdGhvdXQgY29uc3VtZXIgc2lnbmFsaW5nLiAgU29tZSBvZiB1cyBoYXZl IGJlZW4ga2lja2luZyBhcm91bmQgc2ltaWxhcg0KPiBpZGVhcyBpbiB0aGUgYmFjayBjaGFubmVs IGZvciBtb250aHMuDQo+IA0KPiAgICAgSSBhZ3JlZSAtIG9uZSBpcyBuZWVkZWQuIFRoZSBwcm9i bGVtIHdpbGwgYXJpc2UgaWYgdGhlIG1lYW5pbmcgaW1wbGllZA0KPiAgICAgYnkgdGhlIFVJIGlz IGRpZmZlcmVudCBmcm9tIHRoZSBtZWFuaW5nIHNwZWNpZmllZCBmb3IgdGhlIHJlc3BvbnNlIGNv ZGUuDQo+ICAgICBNb3N0IHBlb3BsZSBkb24ndCByZWFkIGEgdXNlciBndWlkZSwgbXVjaCBsZXNz IGFuIFJGQywgdG8gbGVhcm4gdGhlDQo+ICAgICBtZWFuaW5nIG9mIGEgVUkgZWxlbWVudC4gVGhl eSBpbnR1aXQgdGhlIG1lYW5pbmcsIG9yIGhhdmUgaXQgaW5mb3JtYWxseQ0KPiAgICAgZXhwbGFp bmVkIHRvIHRoZW0gYnkgc29tZWJvZHkuIFNvIHRoZSBpbnR1aXRpdmUgbWVhbmluZyBoYWQgYmV0 dGVyIGFsaWduDQo+ICAgICB3aXRoIHRoZSByZXNwb25zZSBjb2RlLiBUaGF0IG1heSBtZWFuIHdl IGhhdmUgdG8gZGVmaW5lIHRoZSBjb2RlIHBvaW50DQo+ICAgICB3aGlsZSB3YWZmbGluZyBvbiBp dHMgcHJlY2lzZSBzZW1hbnRpY3MuDQo+IA0KPiANCj4gUlM+ICBJIHRvdGFsbHkgdW5kZXJzdGFu ZCBidXQgd2UgYXJlIG5vdCB0aGUgcHJvdG9jb2wgcG9saWNlIG11Y2ggbGVzcyB0aGUgVUkNCj4g cG9saWNlLiAgSWYgd2UgZGVmaW5lIHRoZSByZXNwb25zZSBjb2RlIHByZWNpc2VseSB0aGVuIHdl IHNpbXBseSBoYXZlIHRvDQo+IHRydXN0IHRoZSBVRSB0byByZXNwb25kIGNvcnJlY3RseS4gIFBs dXMgc29tZSBvZiB0aGUgY3VycmVudCB0aGlua2luZyBpcw0KPiBWYWxpZGF0ZWQgbWlnaHQgYmUg Y291bGQgYmUgY29tbW9ubHkgcmVwcmVzZW50ZWQgd2l0aGluIHRoZSBpbmR1c3RyeSBhcyBhDQo+ IGdyZWVuIGNoZWNrIGJ1dCBJ4oCZbSB3aWxsaW5nIHRvIGdyYW50IHRoZSBjYXJyaWVycyBhbmQg dGhlIFBCWCB2ZW5kb3JzIHNvbWUNCj4gc2xhY2sgb24gaG93IHRoZXkgbWlnaHQgYWRkIHNvbWUg dmFsdWUgaGVyZS4gVGhpcyBkZWJhdGUgaXMgZ29pbmcgb24gcmlnaHQNCj4gbm93LiBXaGF0IGNv dWxkIGJlIGluZHVzdHJ5IHdpZGUgY29uc2VudGVkIGluIHRoZSBVRSBEaXNwbGF5IHZzIHZhbHVl IGFkZC4NCj4gDQo+IFRoYXQgc2FpZCB0aGlzIGhhZCBiZXR0ZXIgYmUgZGFtbiBzaW1wbGUgYW5k IHdlIGNhbuKAmXQgdHJ5IGFuZCBzb2x2ZSBldmVyeQ0KPiBjb3JuZXIgY2FzZSBpbiB0aGUgaW5p dGlhbCBkZXBsb3ltZW50cy4gIFRoYXQgaXMgbXkgYXJndW1lbnQgb24gcmluZ3Mgb2YNCj4gZGVm ZW5zZS4NCj4gDQo+IFRoZSBwcm9ibGVtIHdpdGggc3Bvb2ZpbmcgYW5kIHJvYm9jYWxscyBpcyB0 aGF0IHRoZSB0b3RhbGl0eSBvZiB0aGUgcHJvYmxlbQ0KPiBoYXMgbWFkZSBjb25zdW1lcnMgZmVl bCBoZWxwbGVzcyBhbmQgdGhhdCBpcyBub3QgYSBnb29kIHRoaW5nLiBJIHJhbiBhY3Jvc3MNCj4g dGhpcyByZWNlbnRseSBhbmQgaXQgaXMgdG90YWxseSBhcHByb3ByaWF0ZSB0byB0aGlzIGNvbnRl eHQuDQo+IA0KPiBodHRwczovL3d3dy5uaXN0Lmdvdi9uZXdzLWV2ZW50cy9uZXdzLzIwMTYvMTAv c2VjdXJpdHktZmF0aWd1ZS1jYW4tDQo+IGNhdXNlLWNvbXB1dGVyLXVzZXJzLWZlZWwtaG9wZWxl c3MtYW5kLWFjdC1yZWNrbGVzc2x5DQo+IA0KPiANCj4gSeKAmWQgcmVhbGx5IGxpa2UgdG8gaGVh ciB5b3VyIHZpZXdzIG9uIGhvdyB0byByYXBpZGx5IG1vdmUgdGhpcyBjb25jZXB0IGFsb25nLg0K PiBUaGUgSUVURiBkb2VzIG5vdCBoYXZlIGEgcGFydGljdWxhcmx5IGdvb2QgdHJhY2sgcmVjb3Jk IHJlY2VudGx5IG9uIHN3aWZ0IGFuZA0KPiBkZWNpc2l2ZSBhY3Rpb24uICBXaGF0IEkgY2FuIHRl c3RpZnkgdG8gKGFuZCByZWNlbnRseSBoYXZlKSBpcyB0aGVyZSBpcw0KPiBjb21taXRtZW50IHRv IGRlcGxveSBhbmQgYSByYXRoZXIgdW5pcXVlIGFsaWdubWVudCBvZiBpbmR1c3RyeSBhbmQNCj4g cmVndWxhdG9yeSBvYmplY3RpdmVzLg0KPiANCj4gDQo+IA0KPiANCj4gICAgIAlUaGFua3MsDQo+ ICAgICAJUGF1bA0KPiANCj4gICAgID4gSSB0b3RhbGx5IHN1cHBvcnQgYWRvcHRpb24gb2YgSGVu bmluZ+KAmXMgZHJhZnRzLiAgSG9wZWZ1bGx5IHRoZXJlIGlzDQo+IGNvbnNlbnN1cyB0aGF0IHdl IGRvbuKAmXQgbmVlZCBhIG5ldyBXRyBmb3IgdGhpcy4gIEkgZG8gTk9UIHN1cHBvcnQgYSBuZXcN Cj4gV0cuICBUaGUgbmVlZCBpcyBzbyBjcml0aWNhbCBhbmQgdGhlIHBvdGVudGlhbCBmb3IgaW1t ZWRpYXRlIGFkb3B0aW9uIGlzIHNvDQo+IGdyZWF0IHdlIG5lZWQgdG8gbW92ZSB0aGlzIGFsb25n IHBlcmhhcHMgaW4gc29tZSBvdGhlciB3YXkuDQo+ICAgICA+DQo+ICAgICA+IFBlcnNvbmFsbHkg SeKAmW0gdG90YWxseSBpbiBmYXZvciBvZiA2NjYuICBJIHRob3VnaHQgdGhhdCBtaWdodCB3b3Jr IGZvciBhDQo+IHByb3Bvc2VkIFBzdWVkby1BTkkgY29kZSBmb3IgaWRlbnRpZnlpbmcgaW50ZXJu YXRpb25hbCBjYWxsIGdhdGV3YXlzLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiDigJQNCj4g ICAgID4gUmljaGFyZCBTaG9ja2V5DQo+ICAgICA+DQo+ICAgICA+IFNob2NrZXkgQ29uc3VsdGlu ZyBMTEMNCj4gICAgID4NCj4gICAgID4gQ2hhaXJtYW4gb2YgdGhlIEJvYXJkIFNJUCBGb3J1bQ0K PiAgICAgPg0KPiAgICAgPiB3d3cuc2hvY2tleS51cw0KPiAgICAgPg0KPiAgICAgPiB3d3cuc2lw Zm9ydW0ub3JnDQo+ICAgICA+DQo+ICAgICA+IHJpY2hhcmQ8YXQ+c2hvY2tleS51cw0KPiAgICAg Pg0KPiAgICAgPiBTa3lwZS1MaW5rZWRpbi1GYWNlYm9vayByc2hvY2tleTEwMQ0KPiAgICAgPg0K PiAgICAgPiBQU1ROICsxIDcwMy01OTMtMjY4Mw0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0K PiAgICAgPiBPbiAxMC83LzE2LCAxMTozMyBBTSwgImRpc3BhdGNoIG9uIGJlaGFsZiBvZiBNaWNo YWVsIEhhbW1lciINCj4gPGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mDQo+ IG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20+IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPiAg ICAgUGF1bCwNCj4gICAgID4NCj4gICAgID4gICAgIFVuZGVyc3RhbmQuICBCdXQsIHRoaXMgaXMg Y2hpY2tlbiBvciBlZ2cgaXNzdWUuDQo+ICAgICA+ICAgICBBbiBhcHAgZGV2ZWxvcGVyIGNhbid0 IGRvIHRoZSBVSSB3aXRob3V0IHRoZSBwcm90b2NvbCBlbGVtZW50IHRvDQo+IG1ha2UgaXQNCj4g ICAgID4gICAgIHVzZWZ1bC4NCj4gICAgID4NCj4gICAgID4gICAgIEFncmVlIHdpdGggdGhvdWdo dCB0aGF0IGEgc2luZ2xlICJzcGFtIiBidXR0b24gbWF5IGJlIGVub3VnaCBvZiBhbg0KPiAgICAg PiAgICAgaW5kaWNhdG9yLg0KPiAgICAgPiAgICAgT3BlcmF0b3Igd291bGQgaGF2ZSB0byBkZWNp ZGUgYXQgd2hhdCBzdGF0aXN0aWNhbCBsZXZlbCB0byBzdGFydCB0YWdnaW5nDQo+IG5ldw0KPiAg ICAgPiAgICAgY2FsbHMgd2l0aCAicG9zc2libGUgc3BhbSIgbGFiZWwuDQo+ICAgICA+DQo+ICAg ICA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgPiAgICAgTWlj aGFlbCBIYW1tZXINCj4gICAgID4gICAgIG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20NCj4g ICAgID4gICAgICsxIDQwOCAyMDIgOTI5MQ0KPiAgICAgPg0KPiAgICAgPiAgICAgwqkgMjAxNiBZ YWFuYSBUZWNobm9sb2dpZXMsIExMQy4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4gRW1haWwNCj4gY29u ZmlkZW50aWFsaXR5DQo+ICAgICA+ICAgICBub3RpY2UuIFRoaXMgbWVzc2FnZSBpcyBwcml2YXRl IGFuZCBjb25maWRlbnRpYWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkDQo+IHRoaXMNCj4gICAgID4g ICAgIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYW5kIHJlbW92ZSBpdCBmcm9t IHlvdXIgc3lzdGVtLg0KPiAgICAgPg0KPiAgICAgPiAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gICAgID4gICAgIEZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdWwNCj4gS3l6aXZhdA0KPiAgICAgPiAgICAgU2Vu dDogVGh1cnNkYXksIE9jdG9iZXIgMDYsIDIwMTYgMjozNCBQTQ0KPiAgICAgPiAgICAgVG86IGRp c3BhdGNoQGlldGYub3JnDQo+ICAgICA+ICAgICBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSA0eHgg dnMgNnh4ICh3YXMgUmU6IFR3byBuZXcgVm9JUCBzcGFtIGRyYWZ0cykNCj4gICAgID4NCj4gICAg ID4gICAgIE9uIDEwLzYvMTYgMTo0OCBQTSwgTWljaGFlbCBIYW1tZXIgd3JvdGU6DQo+ICAgICA+ ICAgICA+IEkgbGlrZSB0aGUgaWRlYSBvZiBhIHVuaXF1ZSBub24tb3ZlcmxvYWRlZCBjb2RlIHBv aW50IHRoYXQNCj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gY2FuIGJlIHVzZWQgdG8gZHJp dmUgc29tZSBwZWctY291bnRzIG9yIGJpZyBkYXRhIGFuYWx5c2lzIG9mIGNhbGxzDQo+ICAgICA+ ICAgICA+DQo+ICAgICA+ICAgICA+IHRvIGhpZ2hsaWdodCB0aGUgbnVtYmVycyBhbmQgcmF0ZXMg aW4gcmVhbC10aW1lLCBzbyB0aGF0DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+IHN5c3Rl bXMgY291bGQgcHJvYWN0aXZlbHkgdGFnIG5leHQgY2FsbHMgdG8gc2F5IHRvIGNhbGxlZCB1c2Vy DQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAgICA+IHRoYXQgdGhpcyBuZXh0IGNhbGwgaGFkIDEw MCwwMDAgdXNlcnMgc2F5aW5nIGl0IHdhcyBhIHJvYm8tY2FsbC4NCj4gICAgID4NCj4gICAgID4g ICAgIFRoaXMgd291bGQgYmUgbmljZS4gQnV0IGl0IGRlcGVuZHMgb24gbW9yZSB0aGFuIGEgdW5p cXVlIHJlc3BvbnNlDQo+IGNvZGUuDQo+ICAgICA+ICAgICBJdCBhbHNvIG5lZWRzIGZvciB1c2Vy cyB0byBvbmx5IHVzZSB0aGF0IGNvZGUgZm9yIHRoZSBzZW1hbnRpYyB5b3Ugd2FudA0KPiB0bw0K PiAgICAgPiAgICAgdGFnIGl0IHdpdGguIFRoaXMgZGVwZW5kcyBhcyBtdWNoIG9uIHRoZSBVSSBw cm92aWRlZCB0byB1c2VycyBhcyBpdCBkb2VzDQo+IG9uDQo+ICAgICA+ICAgICB0aGUgZXhpc3Rl bmNlIG9mIHRoZSBjb2RlKHMpLg0KPiAgICAgPg0KPiAgICAgPiAgICAgT2YgbmVjZXNzaXR5IHRo ZSBVSSB3aWxsIGJlIHNpbXBsZSwgd2l0aCBmZXcgY2hvaWNlcyBmb3IgaG93IHRvIHJlamVjdCBh DQo+ICAgICA+ICAgICBjYWxsLiAoSSBndWVzcyBvbmUgb3IgcG9zc2libHkgdHdvLikgVGhvc2Ug Y2FuIHRoZW4gYmUgbWFwcGVkIHRvDQo+IHBhcnRpY3VsYXINCj4gICAgID4gICAgIHJlc3BvbnNl IGNvZGVzLiBCdXQgaXQgd2lsbCBiZSBoYXJkIHRvIGdldCB1c2VycyB0byB1c2UgdGhvc2UgYnV0 dG9ucyBmb3INCj4gICAgID4gICAgIHByZWNpc2VseSB0aGUgc2VtYW50aWNzIHdlIHdhbnQgdG8g YXNjcmliZSB0byB0aGUgY29kZXMuIChEbyB3ZSB3ZQ0KPiB3YW50IHRoZQ0KPiAgICAgPiAgICAg YnV0dG9uIHRvIG1lYW4gInVud2FudGVkIHJvYm8tY2FsbCIsICJjYWxsIGZyb20gdW5kZXNpcmVk IGNhbGxlciIsDQo+ICAgICA+ICAgICAib2JqZWN0aW9uYWJsZSBjYWxsIGNvbnRlbnQiLCBvciB3 aGF0PykNCj4gICAgID4NCj4gICAgID4gICAgIEV2ZW4gdGhvdWdoIHRoZSBJRVRGIGRvZXNuJ3Qg ImRvIiBVSXMsIGl0IG1pZ2h0IGJlIGJldHRlciB0byBkaXNjdXNzIHRoZQ0KPiAgICAgPiAgICAg bGlrZWx5IFVJIGJlZm9yZSBmdWxseSBkZWZpbmluZyB0aGUgY29kZShzKS4NCj4gICAgID4NCj4g ICAgID4gICAgIAlUaGFua3MsDQo+ICAgICA+ICAgICAJUGF1bA0KPiAgICAgPg0KPiAgICAgPiAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAg ID4gICAgIGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiAgICAgPiAgICAgZGlzcGF0Y2hAaWV0Zi5v cmcNCj4gICAgID4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlz cGF0Y2gNCj4gICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ICAgICA+ICAgICBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gICAgID4gICAg IGRpc3BhdGNoQGlldGYub3JnDQo+ICAgICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ DQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From nobody Sun Oct 9 03:03:40 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0701294A0 for ; Sun, 9 Oct 2016 03:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 5ZfWGIid9JkV for ; Sun, 9 Oct 2016 03:03:36 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0088.outbound.protection.outlook.com [104.47.38.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E6D12948F for ; Sun, 9 Oct 2016 03:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9yjtXcccWbqYllbD6hF9I+vnxC2XA28e4X2SFu/4org=; b=Je2sq6xm8Tr1uQJqDMyg+0WB/IYFMJ9FI3Ax1gLhjdBAZdNQG7TKAkCU9AVbk+Y1XjplX4OuIuDgquZJmD7gpggkPuOCH0oBBvppbWny4SU/JvKVkv9kv3HRAAzWrODSzgHPLniz6OUq3tKQzRzXhhJ70zTWcCdR71bwPAc4YZ0= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 9 Oct 2016 10:03:34 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0659.018; Sun, 9 Oct 2016 10:03:33 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "DOLLY, MARTIN C" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWiCChSbdPK8EujkTBisLYMl6CdbouAgAADqYCAAAX3AIAAA40AgAAIxgCAATkyAIAABDwAgAA/vgCAAOR1QA== Date: Sun, 9 Oct 2016 10:03:33 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 2b2da075-c045-4eca-93e4-08d3f02b8785 x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 6:G7iQPMCWoybHgN0rGCNF8zMw3tAokC11Znagbdxc7W1WZiuz7TS+k8q0G6mRugKehjSlLUEJ3/CmB4LIiw3jJTDAWfP+KkoHnSQOlb4sHB0lzqvRYr0VaEtCh+n0rnGb/ZBqOADr3gvtWKa0uRIoaffVe61PVJsbefewmjR1Ty1n18r4IgMVtkuIevsKe38uTSxLJhSNdU3EcdfcJn7FTm8kmrsh3D6/6JrTaf3UQ2ggAeaMKInniYmNBT3GlzbvVTO86UpN/TxsRSDRScQG7WgqL4pIdftfM4BGUtOgvQiYbwpqWmYCx+DG31MBIY14; 5:8tK7KaxpFLtCn8t4NRLrlaV+gBlfhT+K9QqQkLhP/HZlEZXgW1vH4lzBg/r1da2LxlN8YYML7QZQhWezfXqa03A7UZiuHHUvPh2Zz+Q6n5ZXmYfbjMB6Op9cckn1ijNRBWp2jp1TEVBGlzMp4SV1gw==; 24:JBzlo13daey3PqKoanZLt1INeXuUIoSUf0j4ycClZw15VMkAUghd0VRlmSllh734o/q/Sxu9cgUwVkH4NTVSYWkMYCZgCSS2vTvx+IE9aqE=; 7:jTNnAFsA37wRntmyPp2j8+nP+jHuiCJcMxm7qgEI6Q04NpPkzWOGXZJq8O4iPqA1Wyk2HmUXAkxAW3GqIdCYnPI2EbGc1JGoVPoYmogiwqd8L326d0xwqRYe/Qu4PRf0VhiENUHln6OgFlZMgyzuaA0YhTGe+GmBlMCuW38YzQuxLWef3X7OgPzlcQz9HYMw6SuixJECeEKs8plw72EWgcWOYbAp/jXhh9wSFCTVWsrTZXjpF7aBON/vcAcciUVH97eyCvahcfr5yiGnljw3y1KtnwNLCAZisXo3Xhzo26ARG8zlXwk8Ar4FgCVlFMis x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 00909363D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(377454003)(24454002)(189002)(13464003)(81166006)(81156014)(76576001)(189998001)(122556002)(19580395003)(19580405001)(74316002)(305945005)(7736002)(97736004)(5001770100001)(8676002)(9686002)(87936001)(2171001)(86362001)(10400500002)(3660700001)(102836003)(68736007)(6116002)(3846002)(586003)(3280700002)(5660300001)(93886004)(5002640100001)(92566002)(7696004)(2950100002)(15975445007)(4326007)(2900100001)(2906002)(106116001)(77096005)(106356001)(101416001)(50986999)(7846002)(33656002)(99286002)(66066001)(76176999)(54356999)(8936002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2016 10:03:33.5939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 10:03:39 -0000 i- I don't think it is such a horrible thing if "spam button" has different= semantics for different networks. Actually, for each network, it would be = a *different* button. I don't think we should assume that we are in the bad= old days of POTS with a *single UI*. Each UE/SP pair may provide a differe= nt UI experience, and this wouldn't be limited just to the spam button. IMH= O this is not an issue, users are already familiar with this concept and I = don't think it is something bothering them. ii- I think, like many other things in practice, what a retargeting/forking= element does with 666 would be mainly determined by "local policy". It cou= ld be a good idea to add a paragraph discussing this aspect -with some exam= ples- but I am not sure mandating a particular set of tightly defined seman= tics is the right approach. I wouldn't think so. Thanks, Tolga > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyziv= at > Sent: Saturday, October 08, 2016 4:21 PM > To: DOLLY, MARTIN C > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts >=20 > On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: > > Not so. SP records code and initiates procedures (reporting, > > blacklist, trace back) >=20 > I assume this is intended as a response to: >=20 > > On Oct 8, 2016, at 12:17 PM, Paul Kyzivat > > wrote: >=20 > >> I agree with all of that. But it says we are defining a code without > >> defining precisely what it means - that we are leaving it to the > >> implementations and UI designers to decide what it means. So the > >> definition of the meaning of the code should be correspondingly vague. >=20 > When I said *we* I meant the people who will collectively be deciding to > approve a new response code. >=20 > Then there are SPs who will be implementing services in the network based > on receiving this code, and device makers who will be designing UI throug= h > which users can cause this code to be signaled. >=20 > It sounds like there may be at least two different services that SPs will > implement based on the new code: (1) a statistical determination of > generally bad actors, and (2) a private blacklist for individual subscrib= ers. >=20 > And in addition to SPs, others (e.g. PBX vendors) may also be implementin= g > (2). >=20 > In addition to the SPs, there may also be others (e.g. PBX vendors) > implementing private blacklists, either for their system as a whole or fo= r each > of their individual users, based on the same codes. >=20 > Who, in this collection of participants should define the precise meaning= of > the code? >=20 > It would be unfortunate if pressing the same button on the phone means > one thing at work, something different on my ATT phone, and something > different from that after I port my phone to Verizon. >=20 > If the intent is that the FCC and the US providers decide the meaning for= the > US, then the definition should reflect that that is what it is. >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Oct 10 07:38:13 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EBE1296EE for ; Mon, 10 Oct 2016 07:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] 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 fdrLZb7rR_5e for ; Mon, 10 Oct 2016 07:38:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB8012968D for ; Mon, 10 Oct 2016 07:38:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EE7A687B4F6C0 for ; Mon, 10 Oct 2016 14:38:06 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9AEc8e4019015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Oct 2016 14:38:09 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9AEc7A6024348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Oct 2016 16:38:07 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.150]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:38:07 +0200 From: "Drage, Keith (Nokia - GB)" To: DISPATCH Thread-Topic: Comments on draft-schulzrinne-dispatch-status-unwanted-00 Thread-Index: AdIi39WxBLfEwvQyTi27dAoblrcAsQ== Date: Mon, 10 Oct 2016 14:38:06 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF8BC6C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] Comments on draft-schulzrinne-dispatch-status-unwanted-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 14:38:13 -0000 Section 4: I am not convinced that section 4 requires any RFC 2219 language. Certainly= use of "MAY" provdes an optional "obligation" which is inconsistent with t= he earlier part of the section. My preference would be to rewrite with enti= rely informative language, as actions with the "MAY" would go beyong what I= interpret as the main part of the scope of the document. Section 6: I consider this would be clearer if the following form is used, as I am not= sure what the "RECOMMENDED" as in "SHOULD" actually means here. Can we rewrite this is the form of: "Because calling party numbers can be s= poofed, this response code MUST only be used if the UAS has some guarantee = of the integrity of the calling party number. [I-D.ietf-stir-rfc4474bis] pr= ovides a means of guaranteeing the integrity of the calling party number. Keith From nobody Mon Oct 10 07:38:17 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF312968D for ; Mon, 10 Oct 2016 07:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] 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 cHN98ITO_wVo for ; Mon, 10 Oct 2016 07:38:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9F5129517 for ; Mon, 10 Oct 2016 07:38:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 609839B8AB94E for ; Mon, 10 Oct 2016 14:38:07 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9AEc954019022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Oct 2016 14:38:09 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9AEc6mm024313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Oct 2016 16:38:08 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.150]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:38:08 +0200 From: "Drage, Keith (Nokia - GB)" To: DISPATCH Thread-Topic: Comments on draft-schulzrinne-dispatch-callinfo-spam-00 Thread-Index: AdIi6EsgJRc68dIMSDq6ikujmk9hPA== Date: Mon, 10 Oct 2016 14:38:07 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF8BC74@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-spam-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 14:38:14 -0000 1) Section 1, 1st paragraph, uses the term "illegal telemarketing" but the = abstract just says "telemarketing". I assume both legal and illegal telemar= keting would fall in scope. 2) Section 1, and section 3. I think any use of the term "emergency" needs = to distance itself from any emergency call in for example "112" or "911" us= age. I would not expect this capability to be used on such emergency calls,= if there is additional data to be provided on such calls, then we have a d= efined way of doing that. 3) Section 1: Text "The Call-Info header field MAY be signed using a future "ppt" extension to [I-D.ietf-stir-rfc4474bis]. To ensure that an untrusted originating caller does not mislead the called party, a new feature tag, sip.call-info.spam, indicates whether the terminating carrier will remove untrusted information." I don't know whether it is intended to define this in the timeframe of this= i-d. If yes, then I assume it will be replaced by a normative reference la= ter in the document. If no, I suggest it is removed, as we should not reall= y hint that future work plan that may or may not exist. 4) Section 1: I would suggest avoing the use of normative language in secti= on 1, which is labelled introduction, particularly as in this case it comes= before section 2 which contains the RFC 2119 language. These requirements = need to appear later in the document. 5) Section 1:=20 " SIP entities MUST add a new Call-Info header field, rather than add parameters to an existing one. There MAY be several Call-Info header fields in one request." It is not clear to me whether multiple generators of Call-Info header field= parameters in accordance with this draft along the call path would create = multiple Call-Info header fields, or would be permitted to combine them int= o one Call-Info header field. Given that there is no indication of which en= tity generated the data, it probably does not matter that they have to be s= eparate Call-Info header fields, only that they are distinct from other Cal= l-Info header field usages. 6) Section 3: Values with parameters and types. There are hints that certai= n parameters carry values, eg. "spam" with a percentage, but no indication = of how the syntax of this works.=20 7) Section 3: There are other parameters and types that could well carry va= lues, such as "business" which could be followed by a company name of busin= ess registration number. Obviously that may sometimes apppear in the From o= r Calling Party ID, but there may be instances where more specific and diff= erent information would be inserted there. 8) Section 3. "spam" appears both as a parameter in its own right, and as = a "type" Under what conditions do you expect one versus the other to be use= d? 9) Section 5: For types, Section 3 states "Additional labels are registered= with IANA." However there seems to be no registration of the values define= d under types. 10) Section 6. The mechanism defined in the security considerations does no= t cater for spoofing by MITM attackers between the registrar and the UA. Ad= ditional security that uses the same security tunnel for both the REGISTER = and the subsequent messages would be needed for that. Keith =09 From nobody Mon Oct 10 07:48:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C12127ABE for ; Mon, 10 Oct 2016 07:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] 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 B490epY0ukD2 for ; Mon, 10 Oct 2016 07:48:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F54112968B for ; Mon, 10 Oct 2016 07:48:39 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BCEF1E7E4792; Mon, 10 Oct 2016 14:38:11 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9AEcDNF019037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 14:38:13 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9AEcBIS024547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 16:38:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.150]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 16:38:11 +0200 From: "Drage, Keith (Nokia - GB)" To: "DOLLY, MARTIN C" , Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWi5mbwfRF3e0mSuJ+VXmt0aKCdTQSAgAADqYCAAAX3AIAAAOoAgAQ4P2A= Date: Mon, 10 Oct 2016 14:38:10 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF8BC7A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <87y4205jkr.fsf@hobgoblin.ariadne.com> , <79CFEE70-AB46-47E1-938F-8CFE990529C5@att.com> In-Reply-To: <79CFEE70-AB46-47E1-938F-8CFE990529C5@att.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF8BC7AFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 14:48:42 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF8BC7AFR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know that this is not handed by IETF documents, but at least for all defi= nitions of a diversion type service I know, then the diverted to user becom= es the destination party and all supplementary services and so on associate= d with the new destination user become the ones that are applicable, not th= e ones associated with the diverting user (there are a few minor exceptions= to this in terms of passing on identities). Therefore I would expect this to follow through that any spamming user that= gets diverted goes on the blacklist of the diverted to user rather the bla= cklist of the diverting user. I believe this corresponds to what Martin is saying. Keith From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTI= N C Sent: 07 October 2016 21:56 To: Paul Kyzivat Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts # goes on his blacklist if he has said service Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 7, 2016, at 4:52 PM, Paul Kyzivat > wrote: On 10/7/16 4:31 PM, Henning Schulzrinne wrote: I would argue that, practically speaking, there's not much difference. This is a statistical indicator, so whether this truly speaks for the principal or his/her vacation sub seems only important at the margins. You could also argue that if you don't trust your colleague to recognize spam calls, you may not want him or her to answer calls for you. You may even answer one of the "industry thought leader" survey calls for that person... Things get slightly trickier if 666 triggers addition to a personal blacklist. Even here, I'd argue that this makes sense. If my colleague is kind enough to answer my calls for the next two weeks, she has every right not to be bothered by the same nuisance caller multiple times. I do run the risk that I won't get out of the next speeding ticket since she didn't contribute to the Police Benevolence Association. This depends a lot on how these responses get used. There is a significant = difference between using this to get a statistical measure from the populat= ion as a whole, and building a personal black-list. I was thinking it might= be used for both. What if the call to me was from my colleague's abusive spouse? I may still = have a need to receive calls from that person even though my colleague does= not. And I don't know if we can assume a forwardee will know that the incoming c= all has been forwarded. Thanks, Paul ------------------------------------------------------------------------ *From:* dispatch > on behalf of Paul Kyzivat > *Sent:* Friday, October 7, 2016 4:18:09 PM *To:* dispatch@ietf.org *Subject:* Re: [dispatch] Two new VoIP spam drafts On 10/7/16 10:18 AM, Dale R. Worley wrote: Henning Schulzrinne > writes: The whole point of the "Unwanted" response is exactly that the UAC is making a decision on behalf of the destination number and all associated destinations (UACs). OTOH, my point is that the 6xx response applies to all forks of the called number, which may not be the destination number. In fact, the called UA doesn't *know* the called number. An interesting point. If my calls are forwarded to a colleague while I am on vacation, and he rejects a caller, does that get handled as *my* preference? If the spam filtering is handled by the same intermediary as the one handling the forwarding then presumably it can be sorted out. But if the filtering is done upstream from where the forwarding is done it may be difficult to tell. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8BADF8BC7AFR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I know that this is not h= anded by IETF documents, but at least for all definitions of a diversion ty= pe service I know, then the diverted to user becomes the destination party and all supplementary services and so on associated with= the new destination user become the ones that are applicable, not the ones= associated with the diverting user (there are a few minor exceptions to th= is in terms of passing on identities).

 <= /p>

Therefore I would expect = this to follow through that any spamming user that gets diverted goes on th= e blacklist of the diverted to user rather the blacklist of the diverting user.

 <= /p>

I believe this correspond= s to what Martin is saying.

 <= /p>

Keith

 <= /p>

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: 07 October 2016 21:56
To: Paul Kyzivat
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts

 

# goes on his blackli= st if he has said service

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: += 1.609.903.3360

Email: md3= 135@att.com

 


On Oct 7, 2016, at 4:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 10/7/16 4:31 PM, Henning Schulzrinne wrote:

I would argue that, practically speaking, there's no= t much difference.

This is a statistical indicator, so whether this tru= ly speaks for the

principal or his/her vacation sub seems only importa= nt at the margins.

You could also argue that if you don't trust your co= lleague to recognize

spam calls, you may not want him or her to answer ca= lls for you. You may

even answer one of the "industry thought leader= " survey calls for that

person...

 

 

Things get slightly trickier if 666 triggers additio= n to a personal

blacklist. Even here, I'd argue that this makes sens= e. If my colleague

is kind enough to answer my calls for the next two w= eeks, she has every

right not to be bothered by the same nuisance caller= multiple times. I

do run the risk that I won't get out of the next spe= eding ticket since

she didn't contribute to the Police Benevolence Asso= ciation.


This depends a lot on how these responses get used. There is a significant = difference between using this to get a statistical measure from the populat= ion as a whole, and building a personal black-list. I was thinking it might= be used for both.

What if the call to me was from my colleague's abusive spouse? I may still = have a need to receive calls from that person even though my colleague does= not.

And I don't know if we can assume a forwardee will know that the incoming c= all has been forwarded.

   Thanks,
   Paul


----------------------------------------------------= --------------------

*From:* dispatch <dispatch-bounces@ietf.org> on behalf of Paul Kyzivat

<pkyziva= t@alum.mit.edu>

*Sent:* Friday, October 7, 2016 4:18:09 PM

*To:* dispatch@= ietf.org

*Subject:* Re: [dispatch] Two new VoIP spam drafts

 

On 10/7/16 10:18 AM, Dale R. Worley wrote:

Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> writes:

 

The whole point of the "Unwanted" response= is

exactly that the UAC is making a decision on behalf = of the destination

number and all associated destinations (UACs).<= /o:p>

 

OTOH, my point is that the 6xx response applies to a= ll forks of the

called number, which may not be the destination numb= er.  In fact, the

called UA doesn't *know* the called number.

 

An interesting point. If my calls are forwarded to a= colleague while I

am on vacation, and he rejects a caller, does that g= et handled as *my*

preference?

 

If the spam filtering is handled by the same interme= diary as the one

handling the forwarding then presumably it can be so= rted out. But if the

filtering is done upstream from where the forwarding= is done it may be

difficult to tell.

 

       Thanks,

       Paul<= /o:p>

 

 

 

_______________________________________________=

dispatch mailing list

dispatch@ietf.o= rg

https://www.ietf.org/mailman/listinfo/dispatch

 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

--_000_949EF20990823C4C85C18D59AA11AD8BADF8BC7AFR712WXCHMBA11z_-- From nobody Mon Oct 10 08:09:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB9D129704 for ; Mon, 10 Oct 2016 08:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 YHYuQgM5TAaT for ; Mon, 10 Oct 2016 08:09:13 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CDD1294BC for ; Mon, 10 Oct 2016 08:09:12 -0700 (PDT) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-04v.sys.comcast.net with SMTP id tcBVbrz2RGkXBtcCWb1aE6; Mon, 10 Oct 2016 15:09:12 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-20v.sys.comcast.net with SMTP id tcCVb6cuDrvZ1tcCVboNM8; Mon, 10 Oct 2016 15:09:12 +0000 To: "Asveren, Tolga" , "DOLLY, MARTIN C" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> From: Paul Kyzivat Message-ID: <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> Date: Mon, 10 Oct 2016 11:09:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCHZj0LiVuVbAQK+dKmbyDJDiQd0iRkiENjiga+GK2bNZUBJ1UeiiTFMqAIsyTqZWFqcH78riPvLycxT3SHWyWGXyyC6tAfFDCDGBuL2Ii1S+4RG27Zm /iOqU96pBdDTlaNli+lXAXv92GSApj1C6zSzG7RiuX7SF9bLKX5FX4rwmC9I8io8cnVhZH25lMX7EqCujH1L+cA1nYhq0VxXxlhLKSXqKvyQS1rh/2GH8B+g Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:09:15 -0000 On 10/9/16 6:03 AM, Asveren, Tolga wrote: > i- I don't think it is such a horrible thing if "spam button" has different semantics for different networks. Actually, for each network, it would be a *different* button. I don't think we should assume that we are in the bad old days of POTS with a *single UI*. Each UE/SP pair may provide a different UI experience, and this wouldn't be limited just to the spam button. IMHO this is not an issue, users are already familiar with this concept and I don't think it is something bothering them. Perhaps that will happen in the spirit of "let 1000 flowers bloom". If we don't know what will work best then some experimentation can be a good thing. But in that case it needs to be handled carefully to avoid confusing end users. That can be handled by having a different UI when the semantics differ. But if this is per-SP, while phone UI is not per-SP, then this could become a problem. (E.g., the iPhone UI stays pretty much the same regardless of what SP you use.) But *we* (IETF) don't control that part, though we need to take account of it. What we do control is the signaling. I find it problematic if these UIs all end up signaling the same code point, and then SPs assume they mean different things and take different actions. If we want to let a 1000 flowers bloom then we ought to provide a corresponding range of code points to represent these nuances. (That *doesn't* mean that the UI will inflict a range of choices on the user each time. It might be that each UI only offers one option. Or maybe there is a choice between a simple option and "advanced" that brings up a more complex interface to describe how you feel about the call.) I have been thinking more about this, trying to relate it to what has been learned about email spam. ISTM that the analogy is not very good: When you mark an email as spam, the body of that email is available to analyze. It can be put in a DB, and then the collection can be analyzed for similarities, and those can then be refined into a filter that distinguishes spam from non-spam. When you mark a phone call as spam, there is much less to work with. If it was marked *before* the call was answered, then all callee had to go on to mark it was the information presented to the callee by the phone UI. (And this is a lot less than was present in the signaling.) If all that comes back to the SP is a single code point (666) meaning "spam", then the SP must guess what it was in the signaling that provoked that response. If the callee rejects the call as "spam" *after* answering the call, then (s)he had additional information to go on - the content of the media. But the SP doesn't know what that content was, and also doesn't know what about that content was objectionable. The only additional information the SP has is that the callee didn't reject it sooner. That might or might not be significant. If it was the content that was objectionable, then it may or may not correlate with with information in the signaling. Bottom line - ISTM there ought to be a mechanism that allows the UI (on behalf of the callee) to choose from a variety of reasons for classifying the calls rejected as spam. And that menu ought to be extensible. This doesn't lend itself to being represented as a response code. This could possibly be handled via a new "protocol" value for the Reason header, thus allowing a whole range of new values. Then every SP or every UI developer could potentially register a new code that lines up with their UI or their algorithm. (Again, I am not suggesting that every UI offer every possibility to the callee.) > ii- I think, like many other things in practice, what a retargeting/forking element does with 666 would be mainly determined by "local policy". It could be a good idea to add a paragraph discussing this aspect -with some examples- but I am not sure mandating a particular set of tightly defined semantics is the right approach. I wouldn't think so. Yes. The obvious situation to me is when a PBX or IVR is present. As long as it is made clear to the deploying organization that they need to consider this and screen spam indications passed back to the SP then it should be ok. OR, the SPs could provision different customer connections regarding whether to act on spam indications or not. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Saturday, October 08, 2016 4:21 PM >> To: DOLLY, MARTIN C >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Two new VoIP spam drafts >> >> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: >>> Not so. SP records code and initiates procedures (reporting, >>> blacklist, trace back) >> >> I assume this is intended as a response to: >> >>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat >> > wrote: >> >>>> I agree with all of that. But it says we are defining a code without >>>> defining precisely what it means - that we are leaving it to the >>>> implementations and UI designers to decide what it means. So the >>>> definition of the meaning of the code should be correspondingly vague. >> >> When I said *we* I meant the people who will collectively be deciding to >> approve a new response code. >> >> Then there are SPs who will be implementing services in the network based >> on receiving this code, and device makers who will be designing UI through >> which users can cause this code to be signaled. >> >> It sounds like there may be at least two different services that SPs will >> implement based on the new code: (1) a statistical determination of >> generally bad actors, and (2) a private blacklist for individual subscribers. >> >> And in addition to SPs, others (e.g. PBX vendors) may also be implementing >> (2). >> >> In addition to the SPs, there may also be others (e.g. PBX vendors) >> implementing private blacklists, either for their system as a whole or for each >> of their individual users, based on the same codes. >> >> Who, in this collection of participants should define the precise meaning of >> the code? >> >> It would be unfortunate if pressing the same button on the phone means >> one thing at work, something different on my ATT phone, and something >> different from that after I port my phone to Verizon. >> >> If the intent is that the FCC and the US providers decide the meaning for the >> US, then the definition should reflect that that is what it is. >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Oct 10 08:30:44 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E257129709 for ; Mon, 10 Oct 2016 08:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 4xA8DAdVmX2C for ; Mon, 10 Oct 2016 08:30:39 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869DB12971B for ; Mon, 10 Oct 2016 08:30:35 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-08v.sys.comcast.net with SMTP id tcWjbCgGY2dNjtcXDbP1QX; Mon, 10 Oct 2016 15:30:35 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-po-01v.sys.comcast.net with SMTP id tcXBbCIASjDPstcXCb9cVu; Mon, 10 Oct 2016 15:30:35 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u9AFUWxr017034; Mon, 10 Oct 2016 11:30:32 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u9AFUWnt017030; Mon, 10 Oct 2016 11:30:32 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Henning Schulzrinne In-Reply-To: (Henning.Schulzrinne@fcc.gov) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 10 Oct 2016 11:30:32 -0400 Message-ID: <87oa2s2pd3.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBzX1smcBc8O5LUgbluzsmjV5DXnavnxQmFtKnZe4KUseTy0X8yEuHIgQ0Xzbmn3Xqa0YWkGynhpMgRf9P7h9/a4oELal3oTbaKOUl4ry/M2CQnBsmFP 1mlkOjsY+tAj7gwQWl6XVJCNCZs/7hAVeTNaOh4YeuCi3x31Tws5KvrhRERnlTAZXWij9C7nEF2/4bmvjXok1JIfN85mYZfhkVc= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:30:43 -0000 Henning Schulzrinne writes: > Can you provide a practical, deployed example where this is not the > case? You seem to have cases in mind that I can't think of. People seem to think that it is common to forward a residential phone to a different residential phone. The potential complexities of how the call reached the destination were the motivation for the creation of History-Info. The RFCs for History-Info give various examples. Dale From nobody Mon Oct 10 09:20:14 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C72129464 for ; Mon, 10 Oct 2016 09:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 qCGVVi_TfILM for ; Mon, 10 Oct 2016 09:20:10 -0700 (PDT) Received: from email1.corp.yaanatech.com (12-229-59-67-static.dzbja.com [12.229.59.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683C512940E for ; Mon, 10 Oct 2016 09:20:10 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Mon, 10 Oct 2016 09:20:10 -0700 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "tasveren@sonusnet.com" , "md3135@att.com" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWizkv0CY4240OFBNqXtqGVyKCd4+SAgAADqYCAAAX3AIAAA40AgAAIxgCAATkxAIAABD0AgAA/vQCAAOXUgIAB57qA//+c3wA= Date: Mon, 10 Oct 2016 16:20:07 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BD03F7A1@sc9-ex2k10mb1.corp.yaanatech.com> References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> In-Reply-To: <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.66] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B8_01D222F0.A2BB8760" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 16:20:12 -0000 ------=_NextPart_000_00B8_01D222F0.A2BB8760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with the idea that the policy on what you do with the call=20 should be left to the respective owners: SP, PBX, end-user. Those are features that should have a range of possibilities. I agree that the semantic associated with the code should be explicit, = but not necessarily precise. "Spam" or "Unwanted call" may be sufficient. UI developers can = follow-up with the 1000 whys. But, it might be wise to walk before running wild with this or you risk confusing users. KISS may be sufficient to start with. ________________________________ Michael Hammer michael.hammer@yaanatech.com +1=A0408 202 9291 =A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you have received = this message in error, please notify us and remove it from your system. -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: Monday, October 10, 2016 11:09 AM To: Asveren, Tolga ; DOLLY, MARTIN C = Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts On 10/9/16 6:03 AM, Asveren, Tolga wrote: > i- I don't think it is such a horrible thing if "spam button" has different semantics for different networks. Actually, for each network, = it would be a *different* button. I don't think we should assume that we = are in the bad old days of POTS with a *single UI*. Each UE/SP pair may provide = a different UI experience, and this wouldn't be limited just to the spam button. IMHO this is not an issue, users are already familiar with this concept and I don't think it is something bothering them. Perhaps that will happen in the spirit of "let 1000 flowers bloom". If we don't know what will work best then some experimentation can be a = good thing. But in that case it needs to be handled carefully to avoid confusing end users. That can be handled by having a different UI when the semantics differ. But if this is per-SP, while phone UI is not per-SP, then this could = become a problem. (E.g., the iPhone UI stays pretty much the same regardless of what SP you use.) But *we* (IETF) don't control that part, though we need to take account = of it. What we do control is the signaling. I find it problematic if these = UIs all end up signaling the same code point, and then SPs assume they mean different things and take different actions. If we want to let a 1000 flowers bloom then we ought to provide a corresponding range of code points to represent these nuances. (That *doesn't* mean that the UI will inflict a range of choices on the user = each time. It might be that each UI only offers one option. Or maybe there is = a choice between a simple option and "advanced" that brings up a more = complex interface to describe how you feel about the call.) I have been thinking more about this, trying to relate it to what has = been learned about email spam. ISTM that the analogy is not very good: When you mark an email as spam, the body of that email is available to analyze. It can be put in a DB, and then the collection can be analyzed = for similarities, and those can then be refined into a filter that = distinguishes spam from non-spam. When you mark a phone call as spam, there is much less to work with. If=20 it was marked *before* the call was answered, then all callee had to go = on to mark it was the information presented to the callee by the phone = UI. (And this is a lot less than was present in the signaling.) If all that comes back to the SP is a single code point (666) meaning "spam", then = the SP must guess what it was in the signaling that provoked that response. If the callee rejects the call as "spam" *after* answering the call, = then (s)he had additional information to go on - the content of the media. = But the SP doesn't know what that content was, and also doesn't know what = about that content was objectionable. The only additional information the SP = has is that the callee didn't reject it sooner. That might or might not be significant. If it was the content that was objectionable, then it may = or may not correlate with with information in the signaling. Bottom line - ISTM there ought to be a mechanism that allows the UI (on behalf of the callee) to choose from a variety of reasons for = classifying the calls rejected as spam. And that menu ought to be extensible. This doesn't lend itself to being represented as a response code. This could possibly be handled via a new "protocol" value for the Reason header, = thus allowing a whole range of new values. Then every SP or every UI = developer could potentially register a new code that lines up with their UI or = their algorithm. (Again, I am not suggesting that every UI offer every = possibility to the callee.) > ii- I think, like many other things in practice, what a retargeting/forking element does with 666 would be mainly determined by "local policy". It could be a good idea to add a paragraph discussing = this aspect -with some examples- but I am not sure mandating a particular set = of tightly defined semantics is the right approach. I wouldn't think so. Yes. The obvious situation to me is when a PBX or IVR is present. As = long as it is made clear to the deploying organization that they need to = consider this and screen spam indications passed back to the SP then it should be = ok. OR, the SPs could provision different customer connections regarding = whether to act on spam indications or not. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: Saturday, October 08, 2016 4:21 PM >> To: DOLLY, MARTIN C >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Two new VoIP spam drafts >> >> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: >>> Not so. SP records code and initiates procedures (reporting,=20 >>> blacklist, trace back) >> >> I assume this is intended as a response to: >> >>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat >> > wrote: >> >>>> I agree with all of that. But it says we are defining a code=20 >>>> without defining precisely what it means - that we are leaving it=20 >>>> to the implementations and UI designers to decide what it means. So = >>>> the definition of the meaning of the code should be correspondingly vague. >> >> When I said *we* I meant the people who will collectively be deciding = >> to approve a new response code. >> >> Then there are SPs who will be implementing services in the network=20 >> based on receiving this code, and device makers who will be designing = >> UI through which users can cause this code to be signaled. >> >> It sounds like there may be at least two different services that SPs=20 >> will implement based on the new code: (1) a statistical determination = >> of generally bad actors, and (2) a private blacklist for individual subscribers. >> >> And in addition to SPs, others (e.g. PBX vendors) may also be=20 >> implementing (2). >> >> In addition to the SPs, there may also be others (e.g. PBX vendors)=20 >> implementing private blacklists, either for their system as a whole=20 >> or for each of their individual users, based on the same codes. >> >> Who, in this collection of participants should define the precise=20 >> meaning of the code? >> >> It would be unfortunate if pressing the same button on the phone=20 >> means one thing at work, something different on my ATT phone, and=20 >> something different from that after I port my phone to Verizon. >> >> If the intent is that the FCC and the US providers decide the meaning = >> for the US, then the definition should reflect that that is what it = is. >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_00B8_01D222F0.A2BB8760 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhBMAzfzqk7mKu8vbItErxUIMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDIyOTAwMDAwMFoXDTE4MDIyODIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWEk4s5ORfNfQ/oXDD k4mHDQDDpO3s2oEy7055JdLoleNQXEJGsv8EsqPagYul55uVZ57tmx2H1LjM6QfD7N821joisKa4 +l92JImsffrTnll8gxJ9VV9/WmGpPWwFg4ipw3qRdDhQJnQiNKzlqPMSIDE76uhrKv3hYE30tVIO R8U9erAprCBoHd2Ch1+pIGlFjl91//BR1sehnJR9Z1gZHMEqjto/jYPR1uEapueR6W+YuL9O9HmW RLA925xiZmzwKqB8HS0wG+PjLnMRnohdIh4e+/FKWksC82rP7vmP3SHOzQKdgdapaavCTx/1ZYiR N6cMT95ZCgB1aHXR1lCfAgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBX iSRv04vVx/Y5lWWITUJhWXUTnhM70UUqIEinNF+cV9+zY0lomYqoB8ovCfWrvx232tzX86NtreSn 9UjhBRj61oqSyK9v6P14dunX1MjRZmOVeKws3+XDS3NPsopui5YOPjSy02qhyVN4tIDCokj71db1 wO7uZ/DehNWkwFUgMKdVKM5LAGIDHgWn2dvzGi+ipdDNjMD2SxMnCSOiZ3z9gh/Yy+flNaXn5vLL O0AJEW5xCl2tbuPh/DghqlaiVeCLaCar3cj2Ka6ew5wRhNpvmno47b0C5w6JDxx++ijXjGPzYr57 J8QvCDs9f3Cn5doEF3bTQmcab+s3VEgIhAt1MYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDEwMTYyMDA2WjAjBgkqhkiG 9w0BCQQxFgQUuJjZUOHurx3eRskYCoBHcWO9rXUwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQTAM386pO5irvL2yLRK8VCDCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwDQYJKoZIhvcNAQEBBQAEggEA fM0ZRo+yU49iFaK3EfcM9xu6iIWKgki8QJ3cciwodFHBqJ/iymV+gaJ8svZLQnJNpy8mZ0A/rc8i agjX5Tpgzb88K0k+gtLLHwwJD6lU6X5JA57lpxVkdewUReUDTjPHrVwKPtGvDZxuG4050vjn1jiV b9NUDqgCj3l37xUlFS8CRvpGZq9WUr1SzoAdAAmDZIOKf1aOHYh/XmGlyoac89wCuFvc/8WDwEZU g3QnjdE2lP/hh9N9S/n7xpkb+iSiAhhtjzmKsrMv/tEtJd5n5OaAySVWuwXycENA8lH3QdjSTnmu X5VG0WxsgdA/mrBrASgAn9zvILaIefGlNo6HIQAAAAAAAA== ------=_NextPart_000_00B8_01D222F0.A2BB8760-- From nobody Mon Oct 10 09:54:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5D129743 for ; Mon, 10 Oct 2016 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 pMKX65r_tT_7 for ; Mon, 10 Oct 2016 09:54:33 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826F3129744 for ; Mon, 10 Oct 2016 09:54:32 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-04v.sys.comcast.net with SMTP id tdpZbLL5H8PeatdqSbQyuL; Mon, 10 Oct 2016 16:54:32 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-11v.sys.comcast.net with SMTP id tdqRbpAOk84W7tdqRbPqM8; Mon, 10 Oct 2016 16:54:32 +0000 To: Michael Hammer , "tasveren@sonusnet.com" , "md3135@att.com" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BD03F7A1@sc9-ex2k10mb1.corp.yaanatech.com> From: Paul Kyzivat Message-ID: <702b2c9b-e363-2a0a-05da-40cea9ba5f96@alum.mit.edu> Date: Mon, 10 Oct 2016 12:54:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BD03F7A1@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfCUL5/3WMc5MOpg1fMDPHmp3D4yshWCfxFnIFDXqs7YosXNkMDOgJWvFZHeUD/w4ApvvayAEJJvZlm6Wtd39ExPP1noHwHtKnRxSkg0+CyLxEZG7yJyh 49XcCiNLYA62WZEzUmril+mpG10U8bnS0s2zqztDGmEW7RA09PDoSBJuggOAHBXfSAXIYtZO1ANtW2m0m8gbkRzRVG2/NttSNZj9mqLcfQQv77/biRczgjpw ku3ofKO3UqHbk15DQ7LaoRm0QZ3AP+njM7hc9i0EFGw= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 16:54:36 -0000 On 10/10/16 12:20 PM, Michael Hammer wrote: > I agree with the idea that the policy on what you do with the call > should be left to the respective owners: SP, PBX, end-user. > Those are features that should have a range of possibilities. > > I agree that the semantic associated with the code should be explicit, but > not necessarily precise. > "Spam" or "Unwanted call" may be sufficient. UI developers can follow-up > with the 1000 whys. > But, it might be wise to walk before running wild with this or you risk > confusing users. > KISS may be sufficient to start with. I agree. But it is worth recognizing the limited nature of the data available to work with, and avoid drawing conclusions that cannot be supported by that data. If you want to make finer grained decisions you need finer grained data to work with. For instance, the callee may reject the call based on the caller name presented, or based on the calling number presented. The calling name may or may not be presented to the callee, and if present it may be sourced in different ways. (E.g., from the display name of From, or P-A-ID, or from the user's local address book.) Without knowledge of this, the SP may blame the call on something the callee didn't see, and that in fact doesn't correlate. So it would be helpful to indicate to the SP in some way what it was that was presented to the callee, or what the callee was objecting to. Thanks, Paul > ________________________________ > Michael Hammer > michael.hammer@yaanatech.com > +1 408 202 9291 > > 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality > notice. This message is private and confidential. If you have received this > message in error, please notify us and remove it from your system. > > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, October 10, 2016 11:09 AM > To: Asveren, Tolga ; DOLLY, MARTIN C > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > On 10/9/16 6:03 AM, Asveren, Tolga wrote: >> i- I don't think it is such a horrible thing if "spam button" has > different semantics for different networks. Actually, for each network, it > would be a *different* button. I don't think we should assume that we are in > the bad old days of POTS with a *single UI*. Each UE/SP pair may provide a > different UI experience, and this wouldn't be limited just to the spam > button. IMHO this is not an issue, users are already familiar with this > concept and I don't think it is something bothering them. > > Perhaps that will happen in the spirit of "let 1000 flowers bloom". > If we don't know what will work best then some experimentation can be a good > thing. > > But in that case it needs to be handled carefully to avoid confusing end > users. That can be handled by having a different UI when the semantics > differ. > > But if this is per-SP, while phone UI is not per-SP, then this could become > a problem. (E.g., the iPhone UI stays pretty much the same regardless of > what SP you use.) > > But *we* (IETF) don't control that part, though we need to take account of > it. What we do control is the signaling. I find it problematic if these UIs > all end up signaling the same code point, and then SPs assume they mean > different things and take different actions. > > If we want to let a 1000 flowers bloom then we ought to provide a > corresponding range of code points to represent these nuances. (That > *doesn't* mean that the UI will inflict a range of choices on the user each > time. It might be that each UI only offers one option. Or maybe there is a > choice between a simple option and "advanced" that brings up a more complex > interface to describe how you feel about the call.) > > I have been thinking more about this, trying to relate it to what has been > learned about email spam. ISTM that the analogy is not very good: > > When you mark an email as spam, the body of that email is available to > analyze. It can be put in a DB, and then the collection can be analyzed for > similarities, and those can then be refined into a filter that distinguishes > spam from non-spam. > > When you mark a phone call as spam, there is much less to work with. If > it was marked *before* the call was answered, then all callee had to go > on to mark it was the information presented to the callee by the phone UI. > (And this is a lot less than was present in the signaling.) If all that > comes back to the SP is a single code point (666) meaning "spam", then the > SP must guess what it was in the signaling that provoked that response. > > If the callee rejects the call as "spam" *after* answering the call, then > (s)he had additional information to go on - the content of the media. But > the SP doesn't know what that content was, and also doesn't know what about > that content was objectionable. The only additional information the SP has > is that the callee didn't reject it sooner. That might or might not be > significant. If it was the content that was objectionable, then it may or > may not correlate with with information in the signaling. > > Bottom line - ISTM there ought to be a mechanism that allows the UI (on > behalf of the callee) to choose from a variety of reasons for classifying > the calls rejected as spam. And that menu ought to be extensible. This > doesn't lend itself to being represented as a response code. This could > possibly be handled via a new "protocol" value for the Reason header, thus > allowing a whole range of new values. Then every SP or every UI developer > could potentially register a new code that lines up with their UI or their > algorithm. (Again, I am not suggesting that every UI offer every possibility > to the callee.) > >> ii- I think, like many other things in practice, what a > retargeting/forking element does with 666 would be mainly determined by > "local policy". It could be a good idea to add a paragraph discussing this > aspect -with some examples- but I am not sure mandating a particular set of > tightly defined semantics is the right approach. I wouldn't think so. > > Yes. The obvious situation to me is when a PBX or IVR is present. As long as > it is made clear to the deploying organization that they need to consider > this and screen spam indications passed back to the SP then it should be ok. > OR, the SPs could provision different customer connections regarding whether > to act on spam indications or not. > > Thanks, > Paul > >> Thanks, >> Tolga >> >>> -----Original Message----- >>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul >>> Kyzivat >>> Sent: Saturday, October 08, 2016 4:21 PM >>> To: DOLLY, MARTIN C >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] Two new VoIP spam drafts >>> >>> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: >>>> Not so. SP records code and initiates procedures (reporting, >>>> blacklist, trace back) >>> >>> I assume this is intended as a response to: >>> >>>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat >>> > wrote: >>> >>>>> I agree with all of that. But it says we are defining a code >>>>> without defining precisely what it means - that we are leaving it >>>>> to the implementations and UI designers to decide what it means. So >>>>> the definition of the meaning of the code should be correspondingly > vague. >>> >>> When I said *we* I meant the people who will collectively be deciding >>> to approve a new response code. >>> >>> Then there are SPs who will be implementing services in the network >>> based on receiving this code, and device makers who will be designing >>> UI through which users can cause this code to be signaled. >>> >>> It sounds like there may be at least two different services that SPs >>> will implement based on the new code: (1) a statistical determination >>> of generally bad actors, and (2) a private blacklist for individual > subscribers. >>> >>> And in addition to SPs, others (e.g. PBX vendors) may also be >>> implementing (2). >>> >>> In addition to the SPs, there may also be others (e.g. PBX vendors) >>> implementing private blacklists, either for their system as a whole >>> or for each of their individual users, based on the same codes. >>> >>> Who, in this collection of participants should define the precise >>> meaning of the code? >>> >>> It would be unfortunate if pressing the same button on the phone >>> means one thing at work, something different on my ATT phone, and >>> something different from that after I port my phone to Verizon. >>> >>> If the intent is that the FCC and the US providers decide the meaning >>> for the US, then the definition should reflect that that is what it is. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Oct 10 10:48:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370D0129585 for ; Mon, 10 Oct 2016 10:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 Ra8pvHbz-X17 for ; Mon, 10 Oct 2016 10:48:32 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 1E245129422 for ; Mon, 10 Oct 2016 10:48:32 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id b81so136957596lfe.1 for ; Mon, 10 Oct 2016 10:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=gsItZlkWUynD2ROnDPuqeLMZY9xkM03UTMeRR5AxmQs=; b=ulAuAajZLv5CanY/y3Bzw8oycdVxO2EGIPoovtfZyhB8NJ2sjLdFPE9lTbfwEGVs3k nV7yQCZnnmyn3d6UFxsSyxCWT26BKH0PpQmHbUnqj//eQCbmpCd7HcPz7DHMW1fWs3av SbiK1+a3XV92mOx9ruoyrDbfZbWuigkRWYGQDvbtIsjS+PmABQZNbWiwFcquLtgMcGh7 UACpq1RfG8YiUFRUh9B+lg4pk7hd7L9qamJeq2Eq3EZxWh7oBxllFhWNPzCG4teFMdj7 Z63bmLOmMe8MwWl78gETaDKVSGIGCByninFiUx+pD7gmCsp6WdD+0vYSmlh1c0ZjJtdb Ch5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=gsItZlkWUynD2ROnDPuqeLMZY9xkM03UTMeRR5AxmQs=; b=WfFO/qjBE9+/8qlMKA8g64OGZ0dzJhBAAQiR6NCDqi9A61FRlpt61FAjXzK/cE8+XX Tn/ZG4HosJZeGxqRs5EGRl61WyPc9nNxwIZ66zt49RS+OT8g2+KAlweGfkCmNcY+uhxy z/ZKJ8G9zncC/gnqnCQlMUynLyBkcXbAa2Pvqx++aZ6K1BTSCZRvrr0eAYt0rHccj74Q KtOJFmDI+pZGQUk2pvCbmRTwFvsYb0QRQDjPAGuDXgnIqDZZZksi4tqufYbUyGnbzI4K mcLII3jK0DOVZsH+xEEUEspHUzKG36wWrU3iz9tEFxS8KpxLdVVepeRHx9nBgIGTmKkx aWDA== X-Gm-Message-State: AA6/9RnhQX2hG7qiJeqgXrckmMJCRtE9jhn5HnnxMftiKDpXlTH+OkQII2c669P7W3ho8pbmMpLYpZVbE+ThW3Cd X-Received: by 10.25.210.198 with SMTP id j189mr13849019lfg.165.1476121708402; Mon, 10 Oct 2016 10:48:28 -0700 (PDT) From: Brett Tate References: (Henning.Schulzrinne@fcc.gov) <87oa2s2pd3.fsf@hobgoblin.ariadne.com> In-Reply-To: <87oa2s2pd3.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQBr0fLBAsp1xXVjMPy+iPMX234XIKNuhE8g Date: Mon, 10 Oct 2016 13:48:27 -0400 Message-ID: <318ffeaf11a0f84b6c3ee5cd1189d462@mail.gmail.com> To: dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:48:34 -0000 > > Can you provide a practical, deployed example > > where this is not the case? You seem to have > > cases in mind that I can't think of. > > People seem to think that it is common to forward > a residential phone to a different residential > phone. The potential complexities of how the call > reached the destination were the motivation for > the creation of History-Info. The RFCs for > History-Info give various examples. I agree that call services such as those discussed within RFC 7131, RFC 5359, and RFC 3725 should be considered when specifying the solution. There is also potentially a security concern associated with declaring unwanted calls. For instance, students may declare calls from teachers as unwanted hoping that subsequent calls from teacher to parent are blocked. However, I'm not sure if worth adding to the Security Consideration section. Because of the mandated behavior within RFC 3261 concerning 6xx, I also agree that the use of 666 instead of a 4xx might not be desirable. If there is a need for a 6xx value, it might also be desirable to define a similar 4xx value (for example see 600/486 comparisons and 606/488 comparisons). From nobody Mon Oct 10 11:17:30 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090912958C for ; Mon, 10 Oct 2016 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.196 X-Spam-Level: X-Spam-Status: No, score=-7.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 26cqjYcr4xuE for ; Mon, 10 Oct 2016 11:17:26 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC065129571 for ; Mon, 10 Oct 2016 11:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cl+3rO3sWlvNEtvIq5I120i0uZ0cWkBQgJu93hNZFwQ=; b=HmGgTCguiz5k5mYTLDdNHiKU644hnh/gtRYW8T0y6fJ/Xpi3H4sCEM/qB79+KZ0BfqVqdk9ALpB8Kw4XW7rbtJRPNTuv8W5nfZW34nmCz6zK0gOVm+Hq3mOYpO5U1jnNyeJdpPe6yENCFwTslPq4VZBnwjRvDzmKXV1OkU5B3io= From: Henning Schulzrinne To: Brett Tate , "dispatch@ietf.org" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIws8jqIJi1PJIEa3EccQvSjRiaCh9uuAgAAA+ZE= Date: Mon, 10 Oct 2016 18:17:20 +0000 Message-ID: References: (Henning.Schulzrinne@fcc.gov) <87oa2s2pd3.fsf@hobgoblin.ariadne.com>, <318ffeaf11a0f84b6c3ee5cd1189d462@mail.gmail.com> In-Reply-To: <318ffeaf11a0f84b6c3ee5cd1189d462@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 1f6df797-3de5-44c9-6f84-08d3f139ad3d x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:NHclciY31IdmpdhSnp0brOHgukLfJUgIyT8LkwaWocuYTEMtWgdOogU/0NzYDcJlaZkfIKZkcT1S8Mw+0YGAP8IoriCCiPwRN0Q4iTJoLQD/WtwoFEMWuraPLGN3S7XTpHUf+XQlCzUblGmELOIEdUttFJtmcW2jaufj4aTsDYJMPm1G09oyiRbc6yz987A0HRZi4jOiVdyVCZwMCjcZKjptIggwjkMOTXf0fvK3Tfq8s7i5DRJTeiWL3QKiVoXK4vz2iLApu8y9AZIvhxhww/g0trD4ZUdaIXjRUa/FT8+L92/I7ZD+hpy+pIEfJdF+; 5:L2w0rSFWJErcNIF+1Ky9MCT6g/5grYj+pEb5FGJcOfqIE2XETMP4+1Afx5wSOPcLJkmSuwP3F2Q6z2EbZEPWvxDNViHh3xgAF5DI1Yl66MtaF1G59waYX+J0ZqTEKZR0vT03qgmYJdk5qnLgjVh1iQ==; 24:jtPh/OpnUppHi64+uXilr0qfniVzXNEPbm92C2cIG2xdF53tfyWbE8f/GIfviTdH96rE+L+8PEMB4/JHHEMME5md0mwuQJvWgl7Urcla66s=; 7:S07KflAcc7ZmbJtmSTQiuOcCJXIWHYvqdMgVkfek9DDdLaMjVrKEmMJTsMLE3Cu7pJLrbwh15kSDzuJuaYGXCJnxyCMrlik40wmMcZStOFI0tCGBbCmNcW7tOuqKGBbxaMfHQSu+77EKKR/5OYITkn1mbt1Mlm0m1iIi4ESDC4g6Rfq2Qsvi0o9PCoG9udP/tCud7+kTv83LkxmbRUnxUqdulCDa6YyUPn/koRkerQ9wrKlQntr2eJg2Qp8mmrxDacl/KykQ0ioxBMO1qgnT5G25yGBW9hR5I26Vi9SjmGUP1R67aW0gLnF7a+yM1iaPSo+E9y2beUlhmFlZOwQPiTPeWvlG6pHmWL4WwRlUqKs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(101416001)(33656002)(10400500002)(86362001)(19625215002)(76576001)(189998001)(7696004)(93886004)(8676002)(122556002)(81156014)(81166006)(19617315012)(11100500001)(2906002)(3280700002)(7736002)(7846002)(7906003)(92566002)(3660700001)(74316002)(5660300001)(5002640100001)(102836003)(6116002)(16236675004)(3846002)(106356001)(106116001)(105586002)(99286002)(586003)(2950100002)(68736007)(15975445007)(19580395003)(87936001)(19580405001)(66066001)(50986999)(8936002)(54356999)(76176999)(2501003)(97736004)(5001770100001)(77096005)(9686002)(2900100001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06347767BF6DA5595B1549BBEADB0CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 18:17:20.9705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 18:17:29 -0000 --_000_CY1PR09MB06347767BF6DA5595B1549BBEADB0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two quick notes: (1) In all the cases mentioned so far, the forwarded-to party is authorized= by the forwarder to handle the call and is typically "administratively" th= e same (same family, colleague within same company, colleague who took over= your job). Except for movie plot scenarios involving romantic rivalries be= tween work colleagues, I'm having a hard time finding one where the forward= er would not be delighted to have fewer robocalls and would not trust the f= orwarded-to party to flag such calls. (2) There is one additional case, but it actually needs the 6xx code: Nomor= obo uses simultaneous ringing to filter call. For unknown numbers, it can d= o a CAPTCHA test ("Please enter 77 if you are a human"). The simul-ring cos= ts money, so combining a third-party filter with a carrier subscriber-black= list might offer a convenient way to combine consumer choice with efficienc= y. They would likely return a 666 if done via SIP. (3) Today, every robocaller is supposed to honor your personal opt-out requ= est, whether they are legally entitled to call you or not. (For example, if= a charity calls your US landline, you can still ask them to never call you= again, and they are obligated to honor that request.) If you forward your calls, the forwarded-to party can do exactly that and n= obody is going to ask you for your social security number. Thus, this "prob= lem" already exists today, but I admit that nobody in the real world has ra= ised this as a concern in any of the TCPA (legal robocall) proceedings that= I'm aware of. (4) People will indeed accidentally or maliciously mark email or calls as s= pam. Smart but delinquent kids can already put teachers on the 10-number SC= R list that many landline services support. This only requires a *-code, no= authentication. For this and other reasons, I do think that it is useful for people to have= the ability to see their personal blacklist and change their mind, at leas= t for numbers that are not known spammers. But that's likely a web page or = app, not a SIP request. (5) I'm happy to add 466 to the draft, but admit that I don't know how this= would work differently in practice, except possibly in the forking case, a= nd in that case, I'm having a hard time thinking of common real-world scena= rios where one party wants to mark the call unwanted, and another wants to = pick up. Clearly, we don't want two spam buttons, as users won't understand= the difference. I realize it's fun to discuss corner cases, but maybe we should learn from = the email world where just about every email client and consumer email serv= ice has this function, without a 20-page description. Thus, I think it would be helpful to focus on consumer scenarios where any = of these issues matters, not just on protocol behavior. Henning ________________________________ From: dispatch on behalf of Brett Tate Sent: Monday, October 10, 2016 1:48:27 PM To: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts > > Can you provide a practical, deployed example > > where this is not the case? You seem to have > > cases in mind that I can't think of. > > People seem to think that it is common to forward > a residential phone to a different residential > phone. The potential complexities of how the call > reached the destination were the motivation for > the creation of History-Info. The RFCs for > History-Info give various examples. I agree that call services such as those discussed within RFC 7131, RFC 5359, and RFC 3725 should be considered when specifying the solution. There is also potentially a security concern associated with declaring unwanted calls. For instance, students may declare calls from teachers as unwanted hoping that subsequent calls from teacher to parent are blocked. However, I'm not sure if worth adding to the Security Consideration section. Because of the mandated behavior within RFC 3261 concerning 6xx, I also agree that the use of 666 instead of a 4xx might not be desirable. If there is a need for a 6xx value, it might also be desirable to define a similar 4xx value (for example see 600/486 comparisons and 606/488 comparisons). _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CY1PR09MB06347767BF6DA5595B1549BBEADB0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two quick notes:


(1) In all the cases mentioned so far, the forwarded-to party is au= thorized by the forwarder to handle the call and is typically "adminis= tratively" the same (same family, colleague within same company, colle= ague who took over your job). Except for movie plot scenarios involving romantic rivalries between work colleagues, I'm h= aving a hard time finding one where the forwarder would not be delighted to= have fewer robocalls and would not trust the forwarded-to party to flag su= ch calls.


(2) There is one additional case, but it actually needs the 6xx cod= e: Nomorobo uses simultaneous ringing to filter call. For unknown numbers, = it can do a CAPTCHA test ("Please enter 77 if you are a human"). = The simul-ring costs money, so combining a third-party filter with a carrier subscriber-blacklist might offer a convenient way to= combine consumer choice with efficiency. They would likely return a 666 if= done via SIP.


(3) Today, every robocaller is supposed to honor your personal opt-= out request, whether they are legally entitled to call you or not. (For exa= mple, if a charity calls your US landline, you can still ask them to never = call you again, and they are obligated to honor that request.)


If you forward your calls, the forwarded-to party can do exactly that an= d nobody is going to ask you for your social security number. Thus, this &q= uot;problem" already exists today, but I admit that nobody in the real= world has raised this as a concern in any of the TCPA (legal robocall) proceedings that I'm aware of.


(4) People will indeed accidentally or maliciously mark email or calls a= s spam. Smart but delinquent kids can already put teachers on the 10-n= umber SCR list that many landline services support. This only requires a *-= code, no authentication.


For this and other reasons, I do think that it is useful for people to h= ave the ability to see their personal blacklist and change their mind, at l= east for numbers that are not known spammers. But that's likely a web page = or app, not a SIP request.


(5) I'm happy to add 466 to the draft, but admit that I don't know = how this would work differently in practice, except possibly in the forking= case, and in that case, I'm having a hard time thinking of common rea= l-world scenarios where one party wants to mark the call unwanted, and another wants to pick up. Clearly, we don't wa= nt two spam buttons, as users won't understand the difference.


I realize it's fun to discuss corner cases, but maybe we should learn fr= om the email world where just about every email client and consumer email s= ervice has this function, without a 20-page description.


Thus, I think it would be helpful to focus on consumer scenarios where a= ny of these issues matters, not just on protocol behavior.


Henning

From: dispatch <dispat= ch-bounces@ietf.org> on behalf of Brett Tate <brett@broadsoft.com>=
Sent: Monday, October 10, 2016 1:48:27 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam drafts
 
> > Can you provide a practical, deployed ex= ample
> > where this is not the case? You seem to have
> > cases in mind that I can't think of.
>
> People seem to think that it is common to forward
> a residential phone to a different residential
> phone.  The potential complexities of how the call
> reached the destination were the motivation for
> the creation of History-Info. The RFCs for
> History-Info give various examples.

I agree that call services such as those discussed within RFC 7131, RFC
5359, and RFC 3725 should be considered when specifying the solution.

There is also potentially a security concern associated with declaring
unwanted calls.  For instance, students may declare calls from teacher= s as
unwanted hoping that subsequent calls from teacher to parent are blocked. However, I'm not sure if worth adding to the Security Consideration
section.

Because of the mandated behavior within RFC 3261 concerning 6xx, I also
agree that the use of 666 instead of a 4xx might not be desirable.  If=
there is a need for a 6xx value, it might also be desirable to define a
similar 4xx value (for example see 600/486 comparisons and 606/488
comparisons).

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

 --_000_CY1PR09MB06347767BF6DA5595B1549BBEADB0CY1PR09MB0634namp_-- From nobody Tue Oct 11 15:00:02 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C846C1295B6 for ; Tue, 11 Oct 2016 15:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 JrS6flq8Uxxk for ; Tue, 11 Oct 2016 14:59:58 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEF31293E8 for ; Tue, 11 Oct 2016 14:59:58 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-04v.sys.comcast.net with SMTP id u55LbuBQEGkXBu55Zb5VPw; Tue, 11 Oct 2016 21:59:57 +0000 Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-po-18v.sys.comcast.net with SMTP id u55Xbce2YDkKEu55YbnZQi; Tue, 11 Oct 2016 21:59:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u9BLxslc012723 for ; Tue, 11 Oct 2016 17:59:54 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u9BLxrlt012720; Tue, 11 Oct 2016 17:59:53 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-Reply-To: (mary.ietf.barnes@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 11 Oct 2016 17:59:53 -0400 Message-ID: <87bmyqzgva.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAsLnok928814H50mnhLnyKc+4/hhN9qo1EN0qjAiErEp6esONtXfTLM5YAKw3T83jKH/0OEiNOzwj8OK8zqzv7qwYpCxCtwszzj+vfXTK0WQ/9ukS4k nI5RlRcbth4u0gUR/V7xXyVzRMmhp/owDv44AzFNXDtpg3j4BewQfwGI Archived-At: Subject: Re: [dispatch] Two week review: Progressing draft-mohali-dispatch-originating-cdiv-parameter as AD sponsored X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 22:00:01 -0000 Review of draft-mohali-dispatch-originating-cdiv-parameter-02 Since 3GPP has a need for this work, and since it is compatible with general SIP usage, I support progressing this document once the following technical issues are resolved. Dale ---------------------------------------------------------------------- These comments are based on my understanding of how the P-Served-User header is used. If my understanding is incorrect, it would probably be useful to revise the text to clarifying the misunderstanding. Technical: - There has been discussion on the Dispatch mailing list of the possibility of multiple P-Served-User headers in one request. But it appears to me that semantically there should never be more then one P-Served-User header field value because the "orig", "orig-cdiv", and "term" session cases are mutually exclusive for a particular session at a particular time. Indeed, since an AS uses P-Served-User to determine the session case, having more than one in a request makes the AS unable to determine the correct behavior. I believe this is why RFC 5502 does not authorize repeating P-Served-User, and why its ABNF does not allow a comma-separated list of values. However, RFC 5502 does not forbid repeating P-Served-User, either. I think it would be useful to either file an erratum to RFC 5502 specifying that P-Served-User cannot be repeated, or insert a clause in this draft updating RFC 5502 in that manner. - It seems that once the originating S-CSCF is done performing the originating services, it must remove the P-Served-User header from the INVITE before sending the INVITE to the transit/terminating proxy, even if that proxy is within the same trust domain. Otherwise, the next proxy will have to obey the P-Served-User header: RFC 5502 section 7.2 A proxy that supports the header MUST, upon receiving from a trusted node the P-Served-User header in initial requests for a dialog or in standalone requests, take the value of the P-Served-User header to represent the served user in operations that require such information. However, this behavior is not specified in RFC 5502 section 7.2, which only described removing P-Served-User when the request crosses a Trust Domain boundary. How does my expectation compare to the behavior of 3GPP systems? Do RFC 5502 sections 7.1 and 7.2 completely describe how 3GPP adds and removes P-Served-User headers? - It seems natural to me for "orig-cdiv" to be an alternative value of the "sescase" parameter. I.e., to change RFC 5502 to sessioncase-param = "sescase" EQUAL ( "orig" / "orig-cdiv" / "term" ) "orig", "term", and "orig-cdiv" are mutually exclusive states of a session, and that fact is naturally expressed by alternative values of a single parameter. (Of course, this change requires numerous small edits in the document.) - This example is given in section 4.2: P-Served-User: ; orig-cdiv; regstate=reg However, the description in section 2 of the proxy behavior that creates a P-Served-User header with "orig-cdiv" is: In that case, the S-CSCF updates the P-Served-User header field content by removing both "sescase" and "regstate" header field parameters and inserting the "orig-cdiv" header field parameter. which can never create a P-Served-User header with both "orig-cdiv" and "regstate". The example should be updated to what can occur in correct processing. - The ABNF in RFC 5502 is incorrect: sessioncase-param = "sescase" EQUAL "orig" / "term" registration-state-param = "regstate" EQUAL "unreg" / "reg" As written, it means: sessioncase-param = ( "sescase" EQUAL "orig" ) / "term" registration-state-param = ( "regstate" EQUAL "unreg" ) / "reg" (because concatenation binds tighter than alternation) whereas what is intended is: sessioncase-param = "sescase" EQUAL ( "orig" / "term" ) registration-state-param = "regstate" EQUAL ( "unreg" / "reg" ) I have filed this as erratum 4827 to 5502 (since 5502 as written did not specify what was intended). Perhaps this draft should normatively update 5502 to fix this. - In section 2, "Proxy behavior and parameter handling", is: In that case, the S-CSCF updates the P-Served-User header field content by removing both "sescase" and "regstate" header field parameters and inserting the "orig-cdiv" header field parameter. However, it seems to me that the URI (PServedUser-value) will also have to be changed. Before diversion, during terminating processing, the header is P-Served-User: sip:terminating-user;sescase=term After diversion, during Originating CDIV processing, the header has to be P-Served-User: sip:originating-user;orig-cdiv Editorial: - The use of the "vspace" element in draft-mohali-dispatch-originating-cdiv-parameter-02.xml is unusual. In places, '' is used to generate what appears to be a paragraph break, but (from the point of view of XML2RFC) is not. In other places, '' is used to break the line but not insert a blank line, although the locations where that is done appear to me to be good places for paragraph breaks. That usage is uncommon in the formatting of RFCs. It seems to me that in both cases, replacing the vspace with a paragraph break (in practice, changing it to "" or "{line break}") would use XML2RFC in a way more consonant with common usage. - In regard to keywords, "5502" is listed in the XML, but it seems that the format "RFC5502" is the more common format. You might want to add the keyword "served user", as that seems to be the standard 3GPP term for the user identity on whose behalf services are being executed. (Or is that unnecessary because "served user" appears in the Abstract?) It would also help if the parameter itself, orig-cdiv, appeared as a keyword. - The long title, "P-Served-User Header Field Parameter for Originating CDIV session case in [SIP]", is correct but hard to read. One alternative is "A P-Served-User Header Field Parameter for the Originating CDIV session case in [SIP]", or "The orig-cdiv parameter of the P-Served-User Header Field for the Originating CDIV session case in [SIP]". Similarly, the start of the Abstract is hard to read: 'This specification defines a new Session Initiation Protocol (SIP) P-Served-User header field parameter, "orig-cdiv-param", which defines the session case ...' I think it would be easier to read as 'This specification defines the "orig-cdiv" parameter of the P-Served-User header field in the Session Initiation Protocol (SIP), which defines the session case...'. - The short title, "orig-cdiv session case" is difficult to understand without the draft as context. Perhaps "P-Served-User parameter orig-cdiv". - The phrase "orig-cdiv-param" and variants of it are used in various places to describe the "orig-cdiv" parameter of the P-Served-User header field. It would be clearer and more correct to use the words '"orig-cdiv" parameter', as "orig-cdiv-param" is only used as a nonterminal in the ABNF. - In section 1.2, "Use Case", is: Indeed, the originating user remains the same and the diverting user's originating services do not have to be triggered as if it was an originating call. For instance, the originating user identity should not be hidden because the diverting user has a privacy service for his/her own identity. In the same manner, some specific services may be triggered when performing a call diversion that would not be for a normal originating call. Reading this text, I am not sure if IMS always processes diversions in a one particular way, and that way is triggered by "orig-cdiv", or if there are alternative ways that IMS allows. (The words "Indeed ... remains ..." implies that a diverted call is always treated as orig-cdiv, but the words "do not have to be triggered", "because the diverting user has a privacy service", "may be triggered" suggest that there are alternative processing choices.) I suspect that there are two allowed alternatives: (1) treat the session as an originating call by the diverting user ("P-Served-User: sip:diverting-user;sescase=orig"), or (2) treat the call as a call-diversion origination by the originating user ("P-Served-User: sip:originating-user;orig-cdiv"). In either case, the text should make it clearer what possibilities are allowed in IMS. - Section 5, "IANA Considerations", is: This specification defines a new P-Served-User header field parameter called orig-cdiv-param in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by [RFC3968]. The syntax is defined in Section 4. The required information is: Header Name References -------------- ------------------ P-Served-User [RFC5502][RFCXXXX] The shown "required information" does not match the structure of the "Header Field Parameters and Parameter Values" registry, which is: Header Field Parameter Name Predefined Values Reference ------------ -------------- ----------------- --------- Accept q No [RFC3261] Accept-Encoding q No [RFC3261] ... However, the original error is in RFC 5502, which did not specify that entries for P-Served-User be put into that registry. (P-Served-User is in the registry "Header Fields", however.) It is not clear to me what the correct way to fix this is, but ultimately, the "Header Field Parameters and Parameter Values" registry must contain these three rows that it does not now contain: Header Field Parameter Name Predefined Values Reference ------------ -------------- ----------------- --------- P-Served-User sescase Yes [RFC5502] P-Served-User regstate Yes [RFC5502] P-Served-User orig-cdiv No [RFC5502] Either this draft could provide all of these registrations, or an erratum for RFC 5502 could provide the first two, and the last one is provided by this draft. In any case, the listed "required information" in this draft needs to be revised. Nits: Abstract This document updates RFC5502 in order to add the originating after CDIV session case. I think this could be clarified by adding double-quotes here: This document updates RFC5502 in order to add the "originating after CDIV" session case. 1.1. General This document extends the P-Served- User header field to include the session case for a forwarded leg when a call diversion service (CDIV) has been invoked. Does this processing apply to all call diversions or only some of them? If it applies in only some cases, I think the sentence needs to be extended as "has been invoked and [certain conditions]." The generic-param of the P-Served-User is extended by the "orig-cdiv- param" created as a new parameter for this Originating_CDIV session case. This isn't quite correct and isn't really how you want to phrase it. Perhaps: The generic-param of the P-Served-User is extended by defining a parameter "orig-cdiv" for the Originating_CDIV session case. But "Originating_CDIV" is used nowhere else in the draft, though "Originating CDIV" (without the underscore) is used in the title. Is this the best term to use, and what is the standard punctuation to use? header field parameter usage, Section 2 specifies the proxy behavior for the new header field parameter handling, and Section 3 discusses I think this reads better if "handling" is moved: "... the proxy behavior for handling the new header field parameter, ..." Section 4 describes the Syntax, s/Syntax/syntax/ header field parameter with the IANA s/the IANA/IANA/ 1.2. Use Case To be able to determine which responsibilities the S-CSCF and the Application Server haves to perform and on which user's behalf, it is necessary to know in which situation is the session and who is the current served user.[RFC5502] defines the originating and terminating session cases. This could be made clearer, and also, it could define "session case": To be able to determine which responsibilities the S-CSCF and the Application Server have to perform and on which user's behalf, it is necessary to know the "session case", which is the current situation of the session, and the current "served user", which is the user on whose behalf originating or terminating services are being performed.[RFC5502] 2. Proxy behavior and parameter handling The orig-cdiv-param header filed parameter can be used inside a trust s/filed/field/ In that case, the S-CSCF updates the P-Served-User header field content by removing both "sescase" and "regstate" header field parameters and inserting the "orig-cdiv" header field parameter. I think it would be clearer if this sentence specified what value is placed (or remains) in the PServedUser-value. However, there is a technical issue above regarding what that value should be. Then the procedure would continue forwarding the INVITE request over to an AS The use of the subjunctive "would" does not match the rest of the section. Better would be "Then the procedure continues by forwarding ...". When the AS receives the INVITE request, it determines that the session case is for "orig-cdiv" session case and will perform the originating services to be executed after retargeting for the served user. It would probably be clearer to add "... the served user, which is the originating user, not the diverting user." 3. Applicability The use of the P-Served-User header field extensions is only applicable inside a Trust Domain for served user. I think the phrase "Trust Domain for served user" is intended to be "Trust Domain for P-Served-User". Both phrases are used in RFC 5502, but the first one appears to be incorrect: If one proxy trusts another proxy, it trusts it for all values of P-Served-User, it does not trust different sets of proxies for different served users -- as is explained the next sentence of the section. 6. Security Considerations As the orig-cdiv-param P-Served-User header field parameter can be This would be easier to read as "As the orig-cdiv-param parameter of P-Served-User can be ...". [END] From nobody Wed Oct 12 06:59:45 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A70129519 for ; Wed, 12 Oct 2016 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 T9SmNgkw7JKF for ; Wed, 12 Oct 2016 06:59:40 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0077.outbound.protection.outlook.com [104.47.38.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877841294D5 for ; Wed, 12 Oct 2016 06:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nTDFoGlB2hLlVeDLkr9NV3riCc+r6Hvj1nbAeRC6eEE=; b=Jx6/H/s8Oowq8yHxUyUQyG2EGkHCnSxbLBfvKJVixXiE0TbaBfG0qBMo9cKxXfxSRfBNjAgucCosB/6PF0QU+p+Lhsc2RaZYcm7t13mWh8dVPEjuDzCMNU6phvTj0xGtlK1sZThP1fDBCpwDPlbqK5hiCQIex6INg4QfH5rWV14= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Wed, 12 Oct 2016 13:59:38 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0659.020; Wed, 12 Oct 2016 13:59:38 +0000 From: "Asveren, Tolga" To: Paul Kyzivat Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWiCChSbdPK8EujkTBisLYMl6CdbouAgAADqYCAAAX3AIAAA40AgAAIxgCAATkyAIAABDwAgAA/vgCAAOR1QIAB6RiAgAMM3EA= Date: Wed, 12 Oct 2016 13:59:37 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> In-Reply-To: <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 6f6caf9a-3851-4252-bb40-08d3f2a8017a x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 6:7lkWTYaku2Ti4wWDkAAxq0Z5H+szD9FREewEI+mqKYc5NiuKcUFvUynILmI7bHwWepLbMJdDiia8uzBEbNiaXFgfbRkghb1jKGmzxuAwxJqo7ZwSwN6Nn5zSTFd+TOJ3J5LvEjwfpyZZcwDqpHCRAmp5KIRW0aF106h8M/GeI2oJnK1vO52ZI4cxanABMZnTCQtW2SgCxOK9+cboCAirdv2J6K24qEaIBH68sgX7nR7hGcY2fY8Hjx5XH1pQQMszqTrCLW6ApFkHVtWa2samr3jzsHGM5RDUTmEnSzRkhtObEGvaT9zMasB8Fd66SDd8; 5:9Gsm2WPBaN0aTV3fkVgTNblybpCkb+3bdxaKB826CPrD+6ypkVirW/MLgLQIdJ1MmJ7iGa5Znqr35uWzYSMc7g6xl/MWCb/3diQCwguatWPkadraOLPpCHcSmuCNQOUJyCFQ1BVghnhHeAnH0aA0pQ==; 24:NZ0+nS9xtwiWE3YJWR2dJkYJ8lUBs0PXaDcHJTnwiihYy15OCHbWIg0Sf090N4oOLZ3XswBOXElndb94psWru73LdmsNeG0PoImMMdqj2s0=; 7:+z4MC3+/rNQOfEG1/91igLKdBRhupLx0nzo3tMIo0C9Y8jBK1bUy03q0QrjAssaIjm3UDsIAphFSVjNuo7cXZDHcwyn/G6T+DCOKo8fRtTPxRZ+AjautsJJrxFzW4VkYxF992I8lPBhdFv2IIUE0mCkrCZO5Tg0xcE6ZTwVqbg1YEiQPIhbgUqek/Ptx2sO/eRo2TvSNgwbtHgwYEChx2cupSlmFz5PcpcZmYJr0eETQuwpA1s9x5V4Jg2Lt1x2SbU8AELMuhX6+IodB+m4sRmRVpQvSFNuEpvymcqtwGkWM2IOcY6UTahgWcynX1wUT5xtyUr8jY4HPMA2E2HPEjWAGlstYtGKC6u54 1LQDqK4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(24454002)(377454003)(199003)(189002)(189998001)(7846002)(68736007)(11100500001)(7736002)(8936002)(105586002)(99286002)(106356001)(106116001)(97736004)(3280700002)(93886004)(586003)(101416001)(102836003)(3846002)(3660700001)(76176999)(54356999)(33656002)(6116002)(74316002)(305945005)(9686002)(10400500002)(4326007)(50986999)(5002640100001)(2900100001)(31430400001)(8676002)(77096005)(110136003)(7696004)(5660300001)(15975445007)(6916009)(2950100002)(92566002)(2906002)(66066001)(76576001)(86362001)(19580395003)(122556002)(81166006)(19580405001)(81156014)(2171001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 13:59:37.9527 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 13:59:43 -0000 Overall, I am in favor of keeping the utility/scope limited to "spam". Just= to list a few points along those lines: i- "666" would indicate that the user considers the call as spam/robocall/a= nnoyance; bottomline being that the user would prefer not to receive calls = originating from the same identity. ii- "666" is not intended to be used for the user to blacklist his mother-i= n-law. That -already- could be done by other means. iii- "666" does not automatically blacklists the number/originating identit= y. It is an input for a spam-blocker service, which possibly can be provide= d by a SP. It also would be an input for a centralized robocall/spam logic,= which possibly is used by multiple SPs and maybe administrated by a nation= al authority. iv- Actual blacklisting rules/service is something to be decided/provided b= y the SP. This, for example, may include other components like a web-interf= ace accessible by users. SP may also provide "likely to be spam" (and simil= ar) indicators for calls depending on existing analysis. v- Consider the above points, I think a 6xx response is the right choice an= d no 4xx response needs to be added/used. vi- SP/Central Authority may perform further analysis for a call, which has= been rejected with "666", e.g. based on CDRs, logs, existing peering relat= ionships etc... Thanks, Tolga > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Monday, October 10, 2016 11:09 AM > To: Asveren, Tolga ; DOLLY, MARTIN C > > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts >=20 > On 10/9/16 6:03 AM, Asveren, Tolga wrote: > > i- I don't think it is such a horrible thing if "spam button" has diffe= rent > semantics for different networks. Actually, for each network, it would be= a > *different* button. I don't think we should assume that we are in the bad > old days of POTS with a *single UI*. Each UE/SP pair may provide a differ= ent > UI experience, and this wouldn't be limited just to the spam button. IMHO > this is not an issue, users are already familiar with this concept and I = don't > think it is something bothering them. >=20 > Perhaps that will happen in the spirit of "let 1000 flowers bloom". > If we don't know what will work best then some experimentation can be a > good thing. >=20 > But in that case it needs to be handled carefully to avoid confusing end = users. > That can be handled by having a different UI when the semantics differ. >=20 > But if this is per-SP, while phone UI is not per-SP, then this could beco= me a > problem. (E.g., the iPhone UI stays pretty much the same regardless of wh= at > SP you use.) >=20 > But *we* (IETF) don't control that part, though we need to take account o= f it. > What we do control is the signaling. I find it problematic if these UIs a= ll end up > signaling the same code point, and then SPs assume they mean different > things and take different actions. >=20 > If we want to let a 1000 flowers bloom then we ought to provide a > corresponding range of code points to represent these nuances. (That > *doesn't* mean that the UI will inflict a range of choices on the user ea= ch > time. It might be that each UI only offers one option. Or maybe there is = a > choice between a simple option and "advanced" that brings up a more > complex interface to describe how you feel about the call.) >=20 > I have been thinking more about this, trying to relate it to what has bee= n > learned about email spam. ISTM that the analogy is not very good: >=20 > When you mark an email as spam, the body of that email is available to > analyze. It can be put in a DB, and then the collection can be analyzed f= or > similarities, and those can then be refined into a filter that distinguis= hes spam > from non-spam. >=20 > When you mark a phone call as spam, there is much less to work with. If > it was marked *before* the call was answered, then all callee had to > go > on to mark it was the information presented to the callee by the phone UI= . > (And this is a lot less than was present in the signaling.) If all that c= omes back > to the SP is a single code point (666) meaning "spam", then the SP must > guess what it was in the signaling that provoked that response. >=20 > If the callee rejects the call as "spam" *after* answering the call, then= (s)he > had additional information to go on - the content of the media. But the = SP > doesn't know what that content was, and also doesn't know what about that > content was objectionable. The only additional information the SP has is = that > the callee didn't reject it sooner. That might or might not be significan= t. If it > was the content that was objectionable, then it may or may not correlate > with with information in the signaling. >=20 > Bottom line - ISTM there ought to be a mechanism that allows the UI (on > behalf of the callee) to choose from a variety of reasons for classifying= the > calls rejected as spam. And that menu ought to be extensible. This doesn'= t > lend itself to being represented as a response code. This could possibly = be > handled via a new "protocol" value for the Reason header, thus allowing a > whole range of new values. Then every SP or every UI developer could > potentially register a new code that lines up with their UI or their algo= rithm. > (Again, I am not suggesting that every UI offer every possibility to the = callee.) >=20 > > ii- I think, like many other things in practice, what a retargeting/for= king > element does with 666 would be mainly determined by "local policy". It co= uld > be a good idea to add a paragraph discussing this aspect -with some > examples- but I am not sure mandating a particular set of tightly defined > semantics is the right approach. I wouldn't think so. >=20 > Yes. The obvious situation to me is when a PBX or IVR is present. As long= as it > is made clear to the deploying organization that they need to consider th= is > and screen spam indications passed back to the SP then it should be ok. O= R, > the SPs could provision different customer connections regarding whether = to > act on spam indications or not. >=20 > Thanks, > Paul >=20 > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul > >> Kyzivat > >> Sent: Saturday, October 08, 2016 4:21 PM > >> To: DOLLY, MARTIN C > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] Two new VoIP spam drafts > >> > >> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: > >>> Not so. SP records code and initiates procedures (reporting, > >>> blacklist, trace back) > >> > >> I assume this is intended as a response to: > >> > >>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat >>> > wrote: > >> > >>>> I agree with all of that. But it says we are defining a code > >>>> without defining precisely what it means - that we are leaving it > >>>> to the implementations and UI designers to decide what it means. So > >>>> the definition of the meaning of the code should be correspondingly > vague. > >> > >> When I said *we* I meant the people who will collectively be deciding > >> to approve a new response code. > >> > >> Then there are SPs who will be implementing services in the network > >> based on receiving this code, and device makers who will be designing > >> UI through which users can cause this code to be signaled. > >> > >> It sounds like there may be at least two different services that SPs > >> will implement based on the new code: (1) a statistical determination > >> of generally bad actors, and (2) a private blacklist for individual > subscribers. > >> > >> And in addition to SPs, others (e.g. PBX vendors) may also be > >> implementing (2). > >> > >> In addition to the SPs, there may also be others (e.g. PBX vendors) > >> implementing private blacklists, either for their system as a whole > >> or for each of their individual users, based on the same codes. > >> > >> Who, in this collection of participants should define the precise > >> meaning of the code? > >> > >> It would be unfortunate if pressing the same button on the phone > >> means one thing at work, something different on my ATT phone, and > >> something different from that after I port my phone to Verizon. > >> > >> If the intent is that the FCC and the US providers decide the meaning > >> for the US, then the definition should reflect that that is what it is= . > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > From nobody Wed Oct 12 07:59:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747E61294CF for ; Wed, 12 Oct 2016 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 Gc32Mvs4fuFh for ; Wed, 12 Oct 2016 07:59:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D01B126B6D for ; Wed, 12 Oct 2016 07:59:16 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9CEtcXB038774; Wed, 12 Oct 2016 10:59:14 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 261q4r0mxx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Oct 2016 10:59:12 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9CExAaf006027; Wed, 12 Oct 2016 10:59:10 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9CEx2MR005795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Oct 2016 10:59:04 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 12 Oct 2016 14:58:46 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.250]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0301.000; Wed, 12 Oct 2016 10:58:45 -0400 From: "DOLLY, MARTIN C" To: "Asveren, Tolga" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWi2HwzrKjG+EiQ+j755/EMs6CdbouAgAADqYCAAAX3AIAAA40AgAAIxgCAATkyAIAABDwAgAA/vgCAAOR1QIAB6RiAgAMM3ECAABTj8w== Date: Wed, 12 Oct 2016 14:58:44 +0000 Message-ID: <9C6A3ADA-A515-43C3-BDE3-C48C2C7FDCA3@att.com> References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9C6A3ADAA51543C3BDE3C48C2C7FDCA3attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610120251 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:59:18 -0000 --_000_9C6A3ADAA51543C3BDE3C48C2C7FDCA3attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1, I agree with your summary Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Oct 12, 2016, at 9:59 AM, Asveren, Tolga > wrote: Overall, I am in favor of keeping the utility/scope limited to "spam". Just= to list a few points along those lines: i- "666" would indicate that the user considers the call as spam/robocall/a= nnoyance; bottomline being that the user would prefer not to receive calls = originating from the same identity. ii- "666" is not intended to be used for the user to blacklist his mother-i= n-law. That -already- could be done by other means. iii- "666" does not automatically blacklists the number/originating identit= y. It is an input for a spam-blocker service, which possibly can be provide= d by a SP. It also would be an input for a centralized robocall/spam logic,= which possibly is used by multiple SPs and maybe administrated by a nation= al authority. iv- Actual blacklisting rules/service is something to be decided/provided b= y the SP. This, for example, may include other components like a web-interf= ace accessible by users. SP may also provide "likely to be spam" (and simil= ar) indicators for calls depending on existing analysis. v- Consider the above points, I think a 6xx response is the right choice an= d no 4xx response needs to be added/used. vi- SP/Central Authority may perform further analysis for a call, which has= been rejected with "666", e.g. based on CDRs, logs, existing peering relat= ionships etc... Thanks, Tolga -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Monday, October 10, 2016 11:09 AM To: Asveren, Tolga >; D= OLLY, MARTIN C > Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts On 10/9/16 6:03 AM, Asveren, Tolga wrote: i- I don't think it is such a horrible thing if "spam button" has different semantics for different networks. Actually, for each network, it would be a *different* button. I don't think we should assume that we are in the bad old days of POTS with a *single UI*. Each UE/SP pair may provide a differen= t UI experience, and this wouldn't be limited just to the spam button. IMHO this is not an issue, users are already familiar with this concept and I do= n't think it is something bothering them. Perhaps that will happen in the spirit of "let 1000 flowers bloom". If we don't know what will work best then some experimentation can be a good thing. But in that case it needs to be handled carefully to avoid confusing end us= ers. That can be handled by having a different UI when the semantics differ. But if this is per-SP, while phone UI is not per-SP, then this could become= a problem. (E.g., the iPhone UI stays pretty much the same regardless of what SP you use.) But *we* (IETF) don't control that part, though we need to take account of = it. What we do control is the signaling. I find it problematic if these UIs all= end up signaling the same code point, and then SPs assume they mean different things and take different actions. If we want to let a 1000 flowers bloom then we ought to provide a corresponding range of code points to represent these nuances. (That *doesn't* mean that the UI will inflict a range of choices on the user each time. It might be that each UI only offers one option. Or maybe there is a choice between a simple option and "advanced" that brings up a more complex interface to describe how you feel about the call.) I have been thinking more about this, trying to relate it to what has been learned about email spam. ISTM that the analogy is not very good: When you mark an email as spam, the body of that email is available to analyze. It can be put in a DB, and then the collection can be analyzed for similarities, and those can then be refined into a filter that distinguishe= s spam from non-spam. When you mark a phone call as spam, there is much less to work with. If it was marked *before* the call was answered, then all callee had to go on to mark it was the information presented to the callee by the phone UI. (And this is a lot less than was present in the signaling.) If all that com= es back to the SP is a single code point (666) meaning "spam", then the SP must guess what it was in the signaling that provoked that response. If the callee rejects the call as "spam" *after* answering the call, then (= s)he had additional information to go on - the content of the media. But the SP doesn't know what that content was, and also doesn't know what about that content was objectionable. The only additional information the SP has is th= at the callee didn't reject it sooner. That might or might not be significant.= If it was the content that was objectionable, then it may or may not correlate with with information in the signaling. Bottom line - ISTM there ought to be a mechanism that allows the UI (on behalf of the callee) to choose from a variety of reasons for classifying t= he calls rejected as spam. And that menu ought to be extensible. This doesn't lend itself to being represented as a response code. This could possibly be handled via a new "protocol" value for the Reason header, thus allowing a whole range of new values. Then every SP or every UI developer could potentially register a new code that lines up with their UI or their algori= thm. (Again, I am not suggesting that every UI offer every possibility to the ca= llee.) ii- I think, like many other things in practice, what a retargeting/forking element does with 666 would be mainly determined by "local policy". It coul= d be a good idea to add a paragraph discussing this aspect -with some examples- but I am not sure mandating a particular set of tightly defined semantics is the right approach. I wouldn't think so. Yes. The obvious situation to me is when a PBX or IVR is present. As long a= s it is made clear to the deploying organization that they need to consider this and screen spam indications passed back to the SP then it should be ok. OR, the SPs could provision different customer connections regarding whether to act on spam indications or not. Thanks, Paul Thanks, Tolga -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Saturday, October 08, 2016 4:21 PM To: DOLLY, MARTIN C > Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: Not so. SP records code and initiates procedures (reporting, blacklist, trace back) I assume this is intended as a response to: On Oct 8, 2016, at 12:17 PM, Paul Kyzivat > wrote: I agree with all of that. But it says we are defining a code without defining precisely what it means - that we are leaving it to the implementations and UI designers to decide what it means. So the definition of the meaning of the code should be correspondingly vague. When I said *we* I meant the people who will collectively be deciding to approve a new response code. Then there are SPs who will be implementing services in the network based on receiving this code, and device makers who will be designing UI through which users can cause this code to be signaled. It sounds like there may be at least two different services that SPs will implement based on the new code: (1) a statistical determination of generally bad actors, and (2) a private blacklist for individual subscribers. And in addition to SPs, others (e.g. PBX vendors) may also be implementing (2). In addition to the SPs, there may also be others (e.g. PBX vendors) implementing private blacklists, either for their system as a whole or for each of their individual users, based on the same codes. Who, in this collection of participants should define the precise meaning of the code? It would be unfortunate if pressing the same button on the phone means one thing at work, something different on my ATT phone, and something different from that after I port my phone to Verizon. If the intent is that the FCC and the US providers decide the meaning for the US, then the definition should reflect that that is what it is. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_9C6A3ADAA51543C3BDE3C48C2C7FDCA3attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1, I agree with your summary

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Oct 12, 2016, at 9:59 AM, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Overall, I am in favor of keeping the utility/scope limited to &= quot;spam". Just to list a few points along those lines:

i- "666" would indicate that the user considers the call as= spam/robocall/annoyance; bottomline being that the user would prefer not t= o receive calls originating from the same identity.
ii- "666" is not intended to be used for the user to blackl= ist his mother-in-law. That -already- could be done by other means.<= br> iii- "666" does not automatically blacklists the number/ori= ginating identity. It is an input for a spam-blocker service, which possibl= y can be provided by a SP. It also would be an input for a centralized robo= call/spam logic, which possibly is used by multiple SPs and maybe administrated by a national authority.
iv- Actual blacklisting rules/service is something to be decided/prov= ided by the SP. This, for example, may include other components like a web-= interface accessible by users. SP may also provide "likely to be spam&= quot; (and similar) indicators for calls depending on existing analysis.
v- Consider the above points, I think a 6xx response is the right cho= ice and no 4xx response needs to be added/used.
vi- SP/Central Authority may perform further analysis for a call, whi= ch has been rejected with "666", e.g. based on CDRs, logs, existi= ng peering relationships etc...


Thanks,
Tolga

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
Sent: Monday, October 10, 2016 11:09 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; DOLLY, MARTIN C<= br>
<md313= 5@att.com>
Cc: di= spatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam d= rafts

On 10/9/16 6:03 AM, Asveren, Tolga wrote:
i- I don't think it is such a horrible thin= g if "spam button" has different
semantics for different networks. Actually,= for each network, it would be a
*different* button. I don't think we should= assume that we are in the bad
old days of POTS with a *single UI*. Each U= E/SP pair may provide a different
UI experience, and this wouldn't be limited= just to the spam button. IMHO
this is not an issue, users are already fam= iliar with this concept and I don't
think it is something bothering them.

Perhaps that will happen in the spirit of &= quot;let 1000 flowers bloom".
If we don't know what will work best then s= ome experimentation can be a
good thing.

But in that case it needs to be handled car= efully to avoid confusing end users.
That can be handled by having a different U= I when the semantics differ.

But if this is per-SP, while phone UI is no= t per-SP, then this could become a
problem. (E.g., the iPhone UI stays pretty = much the same regardless of what
SP you use.)

But *we* (IETF) don't control that part, th= ough we need to take account of it.
What we do control is the signaling. I find= it problematic if these UIs all end up
signaling the same code point, and then SPs= assume they mean different
things and take different actions.

If we want to let a 1000 flowers bloom then= we ought to provide a
corresponding range of code points to repre= sent these nuances. (That
*doesn't* mean that the UI will inflict a r= ange of choices on the user each
time. It might be that each UI only offers = one option. Or maybe there is a
choice between a simple option and "ad= vanced" that brings up a more
complex interface to describe how you feel = about the call.)

I have been thinking more about this, tryin= g to relate it to what has been
learned about email spam. ISTM that the ana= logy is not very good:

When you mark an email as spam, the body of= that email is available to
analyze. It can be put in a DB, and then th= e collection can be analyzed for
similarities, and those can then be refined= into a filter that distinguishes spam
from non-spam.

When you mark a phone call as spam, there i= s much less to work with. If
it was marked *before* the call was answere= d, then all    callee had to
go
on to mark it was the information presented= to the callee by the phone UI.
(And this is a lot less than was present in= the signaling.) If all that comes back
to the SP is a single code point (666) mean= ing "spam", then the SP must
guess what it was in the signaling that pro= voked that response.

If the callee rejects the call as "spa= m" *after* answering the call, then (s)he
had additional information to go on - the c= ontent of the media.  But the SP
doesn't know what that content was, and als= o doesn't know what about that
content was objectionable. The only additio= nal information the SP has is that
the callee didn't reject it sooner. That mi= ght or might not be significant. If it
was the content that was objectionable, the= n it may or may not correlate
with with information in the signaling.

Bottom line - ISTM there ought to be a mech= anism that allows the UI (on
behalf of the callee) to choose from a vari= ety of reasons for classifying the
calls rejected as spam. And that menu ought= to be extensible. This doesn't
lend itself to being represented as a respo= nse code. This could possibly be
handled via a new "protocol" valu= e for the Reason header, thus allowing a
whole range of new values. Then every SP or= every UI developer could
potentially register a new code that lines = up with their UI or their algorithm.
(Again, I am not suggesting that every UI o= ffer every possibility to the callee.)

ii- I think, like many other things in prac= tice, what a retargeting/forking
element does with 666 would be mainly deter= mined by "local policy". It could
be a good idea to add a paragraph discussin= g this aspect -with some
examples- but I am not sure mandating a par= ticular set of tightly defined
semantics is the right approach. I wouldn't= think so.

Yes. The obvious situation to me is when a = PBX or IVR is present. As long as it
is made clear to the deploying organization= that they need to consider this
and screen spam indications passed back to = the SP then it should be ok. OR,
the SPs could provision different customer = connections regarding whether to
act on spam indications or not.

   Thanks,
   Paul

Thanks,
Tolga

-----Original Message-----
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul
Kyzivat
Sent: Saturday, October 08, 2016 4:21 PM
To: DOLLY, MARTIN C <md3135@att.com>
Cc: di= spatch@ietf.org
Subject: Re: [dispatch] Two new VoIP spam d= rafts

On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote:=
Not so. SP records code and initiates proce= dures (reporting,
blacklist, trace back)

I assume this is intended as a response to:=

On Oct 8, 2016, at 12:17 PM, Paul Kyzivat &= lt;pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>> wrote:

I agree with all of that. But it says we ar= e defining a code
without defining precisely what it means - = that we are leaving it
to the implementations and UI designers to = decide what it means. So
the definition of the meaning of the code s= hould be correspondingly
vague.

When I said *we* I meant the people who wil= l collectively be deciding
to approve a new response code.

Then there are SPs who will be implementing= services in the network
based on receiving this code, and device ma= kers who will be designing
UI through which users can cause this code = to be signaled.

It sounds like there may be at least two di= fferent services that SPs
will implement based on the new code: (1) a= statistical determination
of generally bad actors, and (2) a private = blacklist for individual
subscribers.

And in addition to SPs, others (e.g. PBX ve= ndors) may also be
implementing (2).

In addition to the SPs, there may also be o= thers (e.g. PBX vendors)
implementing private blacklists, either for= their system as a whole
or for each of their individual users, base= d on the same codes.

Who, in this collection of participants sho= uld define the precise
meaning of the code?

It would be unfortunate if pressing the sam= e button on the phone
means one thing at work, something differen= t on my ATT phone, and
something different from that after I port = my phone to Verizon.

If the intent is that the FCC and the US pr= oviders decide the meaning
for the US, then the definition should refl= ect that that is what it is.

   Thanks,
   Paul

___________________________________________= ____
dispatch mailing list
dispat= ch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_9C6A3ADAA51543C3BDE3C48C2C7FDCA3attcom_-- From nobody Wed Oct 12 11:44:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9502129572 for ; Wed, 12 Oct 2016 11:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GpIQeST2nA5C for ; Wed, 12 Oct 2016 11:44:31 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 0398212952B for ; Wed, 12 Oct 2016 11:44:31 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id l131so54898821lfl.2 for ; Wed, 12 Oct 2016 11:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1VDUa/G4lNxTnuTUsuOYHr6E7OYc+XOp32Juz1s5ny4=; b=flPaV7iJHSppfK9fRCWJqMqsspSJ9e7PUHAcYN1XIYWv3UUoyFME17SSj4T3592tTJ sawkS28nOzRKk6ha11FEok53HcpL11/dwskV38Y/jAdGVHZcYY74Pks/8Q2tuVPgbEXJ gJP/W0hXx05qB8D4S1VLLIDskB5CbCXG16LmqsmqwsvXDEYt1nYfe1I2nVzLSMFTlX5r zAOiKEj/e6EvTBCIZ+nCHcZAM338NV1M+iwsnD+OgLwW7kaVEvXeE6FHYj/8YmZasUN9 GAC+CowLwSLTfGpWOt8nRd3r3mCdIlecJlYGwsgpWB2XyMyKjqix++aVIcl/LHXoBmPE XdaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1VDUa/G4lNxTnuTUsuOYHr6E7OYc+XOp32Juz1s5ny4=; b=TfvUd14/2K3MQ+iCfh1P6gE7DTYjSSLBthDIw1zJVQS3MPXKXynLjl4V0OD5E7TAo7 7uJKShHoc0vRy1hfJioy1lLy83ggu+BkYctkiNN9ZkQoU6bzpB5ANyrigYPH6wZ9dD8P ZcJhMdrhD0tJvNisvfWKO2/VtVE5fvRWkKhLYdhSrtxwX9Q/WzX3K8cuX0NWhKY2m+Ne k3kLaC7JP+0Bz++qlXC6At6CBIm+kZyaBzi1YB466IgExpujYPQ/QGC1BoSbnnVmzMwc PxbEE9ECTXX/k0fuvPqYEoa/S9RvwXs9LjHUVEDH8SF6k//TXB70zUnDlhufZNCDKaWc BM6g== X-Gm-Message-State: AA6/9RkRFEE4hOkJnhGElcWNuKUDZWlbepCzDSYjPeNXJLQTCOrc65k++1CnkLy47/K7P6pOzxsCWu9O+ZZBJg== X-Received: by 10.194.157.193 with SMTP id wo1mr3552983wjb.22.1476297867674; Wed, 12 Oct 2016 11:44:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.44.104 with HTTP; Wed, 12 Oct 2016 11:44:26 -0700 (PDT) In-Reply-To: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> From: Ranjit Avasarala Date: Wed, 12 Oct 2016 13:44:26 -0500 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=089e0122ebcefc4ce7053eaf61c4 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 18:44:35 -0000 --089e0122ebcefc4ce7053eaf61c4 Content-Type: text/plain; charset=UTF-8 Agree with your summary. Regards Ranjit On Wed, Oct 12, 2016 at 8:59 AM, Asveren, Tolga wrote: > Overall, I am in favor of keeping the utility/scope limited to "spam". > Just to list a few points along those lines: > > i- "666" would indicate that the user considers the call as > spam/robocall/annoyance; bottomline being that the user would prefer not to > receive calls originating from the same identity. > ii- "666" is not intended to be used for the user to blacklist his > mother-in-law. That -already- could be done by other means. > iii- "666" does not automatically blacklists the number/originating > identity. It is an input for a spam-blocker service, which possibly can be > provided by a SP. It also would be an input for a centralized robocall/spam > logic, which possibly is used by multiple SPs and maybe administrated by a > national authority. > iv- Actual blacklisting rules/service is something to be decided/provided > by the SP. This, for example, may include other components like a > web-interface accessible by users. SP may also provide "likely to be spam" > (and similar) indicators for calls depending on existing analysis. > v- Consider the above points, I think a 6xx response is the right choice > and no 4xx response needs to be added/used. > vi- SP/Central Authority may perform further analysis for a call, which > has been rejected with "666", e.g. based on CDRs, logs, existing peering > relationships etc... > > > Thanks, > Tolga > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Monday, October 10, 2016 11:09 AM > > To: Asveren, Tolga ; DOLLY, MARTIN C > > > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Two new VoIP spam drafts > > > > On 10/9/16 6:03 AM, Asveren, Tolga wrote: > > > i- I don't think it is such a horrible thing if "spam button" has > different > > semantics for different networks. Actually, for each network, it would > be a > > *different* button. I don't think we should assume that we are in the bad > > old days of POTS with a *single UI*. Each UE/SP pair may provide a > different > > UI experience, and this wouldn't be limited just to the spam button. IMHO > > this is not an issue, users are already familiar with this concept and I > don't > > think it is something bothering them. > > > > Perhaps that will happen in the spirit of "let 1000 flowers bloom". > > If we don't know what will work best then some experimentation can be a > > good thing. > > > > But in that case it needs to be handled carefully to avoid confusing end > users. > > That can be handled by having a different UI when the semantics differ. > > > > But if this is per-SP, while phone UI is not per-SP, then this could > become a > > problem. (E.g., the iPhone UI stays pretty much the same regardless of > what > > SP you use.) > > > > But *we* (IETF) don't control that part, though we need to take account > of it. > > What we do control is the signaling. I find it problematic if these UIs > all end up > > signaling the same code point, and then SPs assume they mean different > > things and take different actions. > > > > If we want to let a 1000 flowers bloom then we ought to provide a > > corresponding range of code points to represent these nuances. (That > > *doesn't* mean that the UI will inflict a range of choices on the user > each > > time. It might be that each UI only offers one option. Or maybe there is > a > > choice between a simple option and "advanced" that brings up a more > > complex interface to describe how you feel about the call.) > > > > I have been thinking more about this, trying to relate it to what has > been > > learned about email spam. ISTM that the analogy is not very good: > > > > When you mark an email as spam, the body of that email is available to > > analyze. It can be put in a DB, and then the collection can be analyzed > for > > similarities, and those can then be refined into a filter that > distinguishes spam > > from non-spam. > > > > When you mark a phone call as spam, there is much less to work with. If > > it was marked *before* the call was answered, then all callee had > to > > go > > on to mark it was the information presented to the callee by the phone > UI. > > (And this is a lot less than was present in the signaling.) If all that > comes back > > to the SP is a single code point (666) meaning "spam", then the SP must > > guess what it was in the signaling that provoked that response. > > > > If the callee rejects the call as "spam" *after* answering the call, > then (s)he > > had additional information to go on - the content of the media. But the > SP > > doesn't know what that content was, and also doesn't know what about that > > content was objectionable. The only additional information the SP has is > that > > the callee didn't reject it sooner. That might or might not be > significant. If it > > was the content that was objectionable, then it may or may not correlate > > with with information in the signaling. > > > > Bottom line - ISTM there ought to be a mechanism that allows the UI (on > > behalf of the callee) to choose from a variety of reasons for > classifying the > > calls rejected as spam. And that menu ought to be extensible. This > doesn't > > lend itself to being represented as a response code. This could possibly > be > > handled via a new "protocol" value for the Reason header, thus allowing a > > whole range of new values. Then every SP or every UI developer could > > potentially register a new code that lines up with their UI or their > algorithm. > > (Again, I am not suggesting that every UI offer every possibility to the > callee.) > > > > > ii- I think, like many other things in practice, what a > retargeting/forking > > element does with 666 would be mainly determined by "local policy". It > could > > be a good idea to add a paragraph discussing this aspect -with some > > examples- but I am not sure mandating a particular set of tightly defined > > semantics is the right approach. I wouldn't think so. > > > > Yes. The obvious situation to me is when a PBX or IVR is present. As > long as it > > is made clear to the deploying organization that they need to consider > this > > and screen spam indications passed back to the SP then it should be ok. > OR, > > the SPs could provision different customer connections regarding whether > to > > act on spam indications or not. > > > > Thanks, > > Paul > > > > > Thanks, > > > Tolga > > > > > >> -----Original Message----- > > >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul > > >> Kyzivat > > >> Sent: Saturday, October 08, 2016 4:21 PM > > >> To: DOLLY, MARTIN C > > >> Cc: dispatch@ietf.org > > >> Subject: Re: [dispatch] Two new VoIP spam drafts > > >> > > >> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: > > >>> Not so. SP records code and initiates procedures (reporting, > > >>> blacklist, trace back) > > >> > > >> I assume this is intended as a response to: > > >> > > >>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat > >>> > wrote: > > >> > > >>>> I agree with all of that. But it says we are defining a code > > >>>> without defining precisely what it means - that we are leaving it > > >>>> to the implementations and UI designers to decide what it means. So > > >>>> the definition of the meaning of the code should be correspondingly > > vague. > > >> > > >> When I said *we* I meant the people who will collectively be deciding > > >> to approve a new response code. > > >> > > >> Then there are SPs who will be implementing services in the network > > >> based on receiving this code, and device makers who will be designing > > >> UI through which users can cause this code to be signaled. > > >> > > >> It sounds like there may be at least two different services that SPs > > >> will implement based on the new code: (1) a statistical determination > > >> of generally bad actors, and (2) a private blacklist for individual > > subscribers. > > >> > > >> And in addition to SPs, others (e.g. PBX vendors) may also be > > >> implementing (2). > > >> > > >> In addition to the SPs, there may also be others (e.g. PBX vendors) > > >> implementing private blacklists, either for their system as a whole > > >> or for each of their individual users, based on the same codes. > > >> > > >> Who, in this collection of participants should define the precise > > >> meaning of the code? > > >> > > >> It would be unfortunate if pressing the same button on the phone > > >> means one thing at work, something different on my ATT phone, and > > >> something different from that after I port my phone to Verizon. > > >> > > >> If the intent is that the FCC and the US providers decide the meaning > > >> for the US, then the definition should reflect that that is what it > is. > > >> > > >> Thanks, > > >> Paul > > >> > > >> _______________________________________________ > > >> dispatch mailing list > > >> dispatch@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e0122ebcefc4ce7053eaf61c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with your summary.

Regards
Ranjit

On Wed, Oct 12, 2016 at 8:59 AM, Asveren, Tolga <= ;tasveren@sonusn= et.com> wrote:
Overall, I a= m in favor of keeping the utility/scope limited to "spam". Just t= o list a few points along those lines:

i- "666" would indicate that the user considers the call as spam/= robocall/annoyance; bottomline being that the user would prefer not to rece= ive calls originating from the same identity.
ii- "666" is not intended to be used for the user to blacklist hi= s mother-in-law. That -already- could be done by other means.
iii- "666" does not automatically blacklists the number/originati= ng identity. It is an input for a spam-blocker service, which possibly can = be provided by a SP. It also would be an input for a centralized robocall/s= pam logic, which possibly is used by multiple SPs and maybe administrated b= y a national authority.
iv- Actual blacklisting rules/service is something to be decided/provided b= y the SP. This, for example, may include other components like a web-interf= ace accessible by users. SP may also provide "likely to be spam" = (and similar) indicators for calls depending on existing analysis.
v- Consider the above points, I think a 6xx response is the right choice an= d no 4xx response needs to be added/used.
vi- SP/Central Authority may perform further analysis for a call, which has= been rejected with "666", e.g. based on CDRs, logs, existing pee= ring relationships etc...


Thanks,
Tolga

> -----Original Message-----
> From: Paul Kyzivat [mailto:pk= yzivat@alum.mit.edu]
> Sent: Monday, October 10, 2016 11:09 AM
> To: Asveren, Tolga <tasver= en@sonusnet.com>; DOLLY, MARTIN C
> <md3135@att.com>
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Two new VoIP spam drafts
>
> On 10/9/16 6:03 AM, Asveren, Tolga wrote:
> > i- I don't think it is such a horrible thing if "spam bu= tton" has different
> semantics for different networks. Actually, for each network, it would= be a
> *different* button. I don't think we should assume that we are in = the bad
> old days of POTS with a *single UI*. Each UE/SP pair may provide a dif= ferent
> UI experience, and this wouldn't be limited just to the spam butto= n. IMHO
> this is not an issue, users are already familiar with this concept and= I don't
> think it is something bothering them.
>
> Perhaps that will happen in the spirit of "let 1000 flowers bloom= ".
> If we don't know what will work best then some experimentation can= be a
> good thing.
>
> But in that case it needs to be handled carefully to avoid confusing e= nd users.
> That can be handled by having a different UI when the semantics differ= .
>
> But if this is per-SP, while phone UI is not per-SP, then this could b= ecome a
> problem. (E.g., the iPhone UI stays pretty much the same regardless of= what
> SP you use.)
>
> But *we* (IETF) don't control that part, though we need to take ac= count of it.
> What we do control is the signaling. I find it problematic if these UI= s all end up
> signaling the same code point, and then SPs assume they mean different=
> things and take different actions.
>
> If we want to let a 1000 flowers bloom then we ought to provide a
> corresponding range of code points to represent these nuances. (That > *doesn't* mean that the UI will inflict a range of choices on the = user each
> time. It might be that each UI only offers one option. Or maybe there = is a
> choice between a simple option and "advanced" that brings up= a more
> complex interface to describe how you feel about the call.)
>
> I have been thinking more about this, trying to relate it to what has = been
> learned about email spam. ISTM that the analogy is not very good:
>
> When you mark an email as spam, the body of that email is available to=
> analyze. It can be put in a DB, and then the collection can be analyze= d for
> similarities, and those can then be refined into a filter that disting= uishes spam
> from non-spam.
>
> When you mark a phone call as spam, there is much less to work with. I= f
> it was marked *before* the call was answered, then all=C2=A0 =C2=A0 = =C2=A0 =C2=A0 callee had to
> go
> on to mark it was the information presented to the callee by the phone= UI.
> (And this is a lot less than was present in the signaling.) If all tha= t comes back
> to the SP is a single code point (666) meaning "spam", then = the SP must
> guess what it was in the signaling that provoked that response.
>
> If the callee rejects the call as "spam" *after* answering t= he call, then (s)he
> had additional information to go on - the content of the media.=C2=A0 = But the SP
> doesn't know what that content was, and also doesn't know what= about that
> content was objectionable. The only additional information the SP has = is that
> the callee didn't reject it sooner. That might or might not be sig= nificant. If it
> was the content that was objectionable, then it may or may not correla= te
> with with information in the signaling.
>
> Bottom line - ISTM there ought to be a mechanism that allows the UI (o= n
> behalf of the callee) to choose from a variety of reasons for classify= ing the
> calls rejected as spam. And that menu ought to be extensible. This doe= sn't
> lend itself to being represented as a response code. This could possib= ly be
> handled via a new "protocol" value for the Reason header, th= us allowing a
> whole range of new values. Then every SP or every UI developer could > potentially register a new code that lines up with their UI or their a= lgorithm.
> (Again, I am not suggesting that every UI offer every possibility to t= he callee.)
>
> > ii- I think, like many other things in practice, what a retargeti= ng/forking
> element does with 666 would be mainly determined by "local policy= ". It could
> be a good idea to add a paragraph discussing this aspect -with some > examples- but I am not sure mandating a particular set of tightly defi= ned
> semantics is the right approach. I wouldn't think so.
>
> Yes. The obvious situation to me is when a PBX or IVR is present. As l= ong as it
> is made clear to the deploying organization that they need to consider= this
> and screen spam indications passed back to the SP then it should be ok= . OR,
> the SPs could provision different customer connections regarding wheth= er to
> act on spam indications or not.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
>
> > Thanks,
> > Tolga
> >
> >> -----Original Message-----
> >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul
> >> Kyzivat
> >> Sent: Saturday, October 08, 2016 4:21 PM
> >> To: DOLLY, MARTIN C <md3= 135@att.com>
> >> Cc: dispatch@ietf.org
> >> Subject: Re: [dispatch] Two new VoIP spam drafts
> >>
> >> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote:
> >>> Not so. SP records code and initiates procedures (reporti= ng,
> >>> blacklist, trace back)
> >>
> >> I assume this is intended as a response to:
> >>
> >>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
> >>> <mailto:pkyzi= vat@alum.mit.edu>> wrote:
> >>
> >>>> I agree with all of that. But it says we are defining= a code
> >>>> without defining precisely what it means - that we ar= e leaving it
> >>>> to the implementations and UI designers to decide wha= t it means. So
> >>>> the definition of the meaning of the code should be c= orrespondingly
> vague.
> >>
> >> When I said *we* I meant the people who will collectively be = deciding
> >> to approve a new response code.
> >>
> >> Then there are SPs who will be implementing services in the n= etwork
> >> based on receiving this code, and device makers who will be d= esigning
> >> UI through which users can cause this code to be signaled. > >>
> >> It sounds like there may be at least two different services t= hat SPs
> >> will implement based on the new code: (1) a statistical deter= mination
> >> of generally bad actors, and (2) a private blacklist for indi= vidual
> subscribers.
> >>
> >> And in addition to SPs, others (e.g. PBX vendors) may also be=
> >> implementing (2).
> >>
> >> In addition to the SPs, there may also be others (e.g. PBX ve= ndors)
> >> implementing private blacklists, either for their system as a= whole
> >> or for each of their individual users, based on the same code= s.
> >>
> >> Who, in this collection of participants should define the pre= cise
> >> meaning of the code?
> >>
> >> It would be unfortunate if pressing the same button on the ph= one
> >> means one thing at work, something different on my ATT phone,= and
> >> something different from that after I port my phone to Verizo= n.
> >>
> >> If the intent is that the FCC and the US providers decide the= meaning
> >> for the US, then the definition should reflect that that is w= hat it is.
> >>
> >>=C2=A0 =C2=A0 Thanks,
> >>=C2=A0 =C2=A0 Paul
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listin= fo/dispatch
> >

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e0122ebcefc4ce7053eaf61c4-- From nobody Wed Oct 12 12:17:40 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039E812950A for ; Wed, 12 Oct 2016 12:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 kRWseVSB_UVC for ; Wed, 12 Oct 2016 12:17:36 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E207129643 for ; Wed, 12 Oct 2016 12:17:34 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-02v.sys.comcast.net with SMTP id uP1mbPepQ0MKRuP1xbJTJn; Wed, 12 Oct 2016 19:17:33 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-20v.sys.comcast.net with SMTP id uP1wbF87JIwOJuP1xb7eX5; Wed, 12 Oct 2016 19:17:33 +0000 To: "Asveren, Tolga" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> From: Paul Kyzivat Message-ID: <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> Date: Wed, 12 Oct 2016 15:17:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKFfejSn15QZ5W/0GAeREWXCb16o5hbksQ8ZG5wdh5l4j5mmJJvhaWl3CvNBHwBZ8cbaaIjKa/VI7B7YLVDYLSKgfir+ANEJl4ro64id717SZW7/2bWN 65ZVYsf6fiaUZqYiDX5Q/ImS8eK23IQSD0jBJ+bB/SCUKlpMmbw9TkWLi2YUMWztRBGkwt92ETQE2IzDD+Rxf1gpDJUCJfPHJEg= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 19:17:39 -0000 On 10/12/16 9:59 AM, Asveren, Tolga wrote: > Overall, I am in favor of keeping the utility/scope limited to "spam". Just to list a few points along those lines: > > i- "666" would indicate that the user considers the call as spam/robocall/annoyance; bottomline being that the user would prefer not to receive calls originating from the same identity. While this seems reasonable, how will it work in practice? IOW, when will I know to use it? If I use it before I answer the call, then on what basis am I doing so? Is it because I recognize the number? Or is it based on the classification assigned by the provider that has been displayed to me? Will I have an option to use it after I have answered the call? (As an alternative to normal hangup.) If so, and if I do so then based on the content of the call, is the meaning "would prefer not to receive calls originating from the same identity"? I suspect it is really more "would prefer not to receive calls of this type", regardless of the callerid. (Especially when spam often comes from forged IDs.) These are two different semantics. Perhaps they can share the same code, since they can be distinguished because they are signaled in different ways. But it would be cleaner if they were different codes. > ii- "666" is not intended to be used for the user to blacklist his mother-in-law. That -already- could be done by other means. > iii- "666" does not automatically blacklists the number/originating identity. It is an input for a spam-blocker service, which possibly can be provided by a SP. It also would be an input for a centralized robocall/spam logic, which possibly is used by multiple SPs and maybe administrated by a national authority. > iv- Actual blacklisting rules/service is something to be decided/provided by the SP. This, for example, may include other components like a web-interface accessible by users. SP may also provide "likely to be spam" (and similar) indicators for calls depending on existing analysis. I agree these seem like wise policies. > v- Consider the above points, I think a 6xx response is the right choice and no 4xx response needs to be added/used. I'm neutral on this. > vi- SP/Central Authority may perform further analysis for a call, which has been rejected with "666", e.g. based on CDRs, logs, existing peering relationships etc... And statistics. If the same calling number has been flagged by many users *after* they have answered the call, then we can infer that there is a consistent behavior of bad behavior from this ID. That is worth investigating. If the same number has been flagged by many users *before* they have answered the call, but not corroborated by others flagging it after answering, then the situation is unclear. Perhaps this number carries a calling name that leads people to reject it? Or perhaps it is a number that is special enough to be recognized by a lot of people. I think this would need to be investigated carefully to understand what is going on. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Monday, October 10, 2016 11:09 AM >> To: Asveren, Tolga ; DOLLY, MARTIN C >> >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Two new VoIP spam drafts >> >> On 10/9/16 6:03 AM, Asveren, Tolga wrote: >>> i- I don't think it is such a horrible thing if "spam button" has different >> semantics for different networks. Actually, for each network, it would be a >> *different* button. I don't think we should assume that we are in the bad >> old days of POTS with a *single UI*. Each UE/SP pair may provide a different >> UI experience, and this wouldn't be limited just to the spam button. IMHO >> this is not an issue, users are already familiar with this concept and I don't >> think it is something bothering them. >> >> Perhaps that will happen in the spirit of "let 1000 flowers bloom". >> If we don't know what will work best then some experimentation can be a >> good thing. >> >> But in that case it needs to be handled carefully to avoid confusing end users. >> That can be handled by having a different UI when the semantics differ. >> >> But if this is per-SP, while phone UI is not per-SP, then this could become a >> problem. (E.g., the iPhone UI stays pretty much the same regardless of what >> SP you use.) >> >> But *we* (IETF) don't control that part, though we need to take account of it. >> What we do control is the signaling. I find it problematic if these UIs all end up >> signaling the same code point, and then SPs assume they mean different >> things and take different actions. >> >> If we want to let a 1000 flowers bloom then we ought to provide a >> corresponding range of code points to represent these nuances. (That >> *doesn't* mean that the UI will inflict a range of choices on the user each >> time. It might be that each UI only offers one option. Or maybe there is a >> choice between a simple option and "advanced" that brings up a more >> complex interface to describe how you feel about the call.) >> >> I have been thinking more about this, trying to relate it to what has been >> learned about email spam. ISTM that the analogy is not very good: >> >> When you mark an email as spam, the body of that email is available to >> analyze. It can be put in a DB, and then the collection can be analyzed for >> similarities, and those can then be refined into a filter that distinguishes spam >> from non-spam. >> >> When you mark a phone call as spam, there is much less to work with. If >> it was marked *before* the call was answered, then all callee had to >> go >> on to mark it was the information presented to the callee by the phone UI. >> (And this is a lot less than was present in the signaling.) If all that comes back >> to the SP is a single code point (666) meaning "spam", then the SP must >> guess what it was in the signaling that provoked that response. >> >> If the callee rejects the call as "spam" *after* answering the call, then (s)he >> had additional information to go on - the content of the media. But the SP >> doesn't know what that content was, and also doesn't know what about that >> content was objectionable. The only additional information the SP has is that >> the callee didn't reject it sooner. That might or might not be significant. If it >> was the content that was objectionable, then it may or may not correlate >> with with information in the signaling. >> >> Bottom line - ISTM there ought to be a mechanism that allows the UI (on >> behalf of the callee) to choose from a variety of reasons for classifying the >> calls rejected as spam. And that menu ought to be extensible. This doesn't >> lend itself to being represented as a response code. This could possibly be >> handled via a new "protocol" value for the Reason header, thus allowing a >> whole range of new values. Then every SP or every UI developer could >> potentially register a new code that lines up with their UI or their algorithm. >> (Again, I am not suggesting that every UI offer every possibility to the callee.) >> >>> ii- I think, like many other things in practice, what a retargeting/forking >> element does with 666 would be mainly determined by "local policy". It could >> be a good idea to add a paragraph discussing this aspect -with some >> examples- but I am not sure mandating a particular set of tightly defined >> semantics is the right approach. I wouldn't think so. >> >> Yes. The obvious situation to me is when a PBX or IVR is present. As long as it >> is made clear to the deploying organization that they need to consider this >> and screen spam indications passed back to the SP then it should be ok. OR, >> the SPs could provision different customer connections regarding whether to >> act on spam indications or not. >> >> Thanks, >> Paul >> >>> Thanks, >>> Tolga >>> >>>> -----Original Message----- >>>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul >>>> Kyzivat >>>> Sent: Saturday, October 08, 2016 4:21 PM >>>> To: DOLLY, MARTIN C >>>> Cc: dispatch@ietf.org >>>> Subject: Re: [dispatch] Two new VoIP spam drafts >>>> >>>> On 10/8/16 12:32 PM, DOLLY, MARTIN C wrote: >>>>> Not so. SP records code and initiates procedures (reporting, >>>>> blacklist, trace back) >>>> >>>> I assume this is intended as a response to: >>>> >>>>> On Oct 8, 2016, at 12:17 PM, Paul Kyzivat >>>> > wrote: >>>> >>>>>> I agree with all of that. But it says we are defining a code >>>>>> without defining precisely what it means - that we are leaving it >>>>>> to the implementations and UI designers to decide what it means. So >>>>>> the definition of the meaning of the code should be correspondingly >> vague. >>>> >>>> When I said *we* I meant the people who will collectively be deciding >>>> to approve a new response code. >>>> >>>> Then there are SPs who will be implementing services in the network >>>> based on receiving this code, and device makers who will be designing >>>> UI through which users can cause this code to be signaled. >>>> >>>> It sounds like there may be at least two different services that SPs >>>> will implement based on the new code: (1) a statistical determination >>>> of generally bad actors, and (2) a private blacklist for individual >> subscribers. >>>> >>>> And in addition to SPs, others (e.g. PBX vendors) may also be >>>> implementing (2). >>>> >>>> In addition to the SPs, there may also be others (e.g. PBX vendors) >>>> implementing private blacklists, either for their system as a whole >>>> or for each of their individual users, based on the same codes. >>>> >>>> Who, in this collection of participants should define the precise >>>> meaning of the code? >>>> >>>> It would be unfortunate if pressing the same button on the phone >>>> means one thing at work, something different on my ATT phone, and >>>> something different from that after I port my phone to Verizon. >>>> >>>> If the intent is that the FCC and the US providers decide the meaning >>>> for the US, then the definition should reflect that that is what it is. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> > > From nobody Wed Oct 12 12:34:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FB9129655 for ; Wed, 12 Oct 2016 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 hhJsWDHOBQgC for ; Wed, 12 Oct 2016 12:34:15 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D6129656 for ; Wed, 12 Oct 2016 12:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=olcQddf4FRV6uRkAEQoFulDu8KncbopIb6lWGZkeDio=; b=c7xi5HCIMd6TdqrHzNG38mi0WUlP0yP5icDb5jKxBPVeC341y4fKaZjQhJEedFTn6MzPpEH5/nRswURrAkBEkkjl/cHsFNNf3hLXvM4zMXKvRoJ+Xuwkg7lmHgmzYt9pcASlYnQWF+r+5r4Q9qm4bIkGGFVik5tT03WV+GILt18= From: Henning Schulzrinne To: Paul Kyzivat , "Asveren, Tolga" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWijqIJi1PJIEa3EccQvSjRiaCdbouAgAAB3oeAAAfCAIAAAOj2gAALawCAATkyAIAABDwAgAA/vgCAAOXTgIAB57qAgAMROoCAAFjTAIAAAKkQ Date: Wed, 12 Oct 2016 19:34:10 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> In-Reply-To: <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 76e92d83-e8fb-4cba-4e72-08d3f2d6bdb6 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 6:0LxoDE6WHkka0XLV+3pS4kX5w4PhZbRC8oxu/4iOaeiDRrDoEAaK94nc8usWO9z6hI9u1nYbF1r2pmMMBjwj0mff0+2pmLsNT36CboU1GkyQuOhriB2VbU8fzoM9yxUqRCfB04ErKeyXdgaEFryOXEoTf/esxHgk88IYs/jG1ac7qvflm+d0u+iLumaycUZItZgTSApjURPL+XUPhRRJOpDNOVwKZ+M6V8a1gNKMRkmcqp4qlsyTUWPgrn2ikyHo35uvn/EqMmgdZrA0lGeyJ04N4BMBivgNTrVlc8ZCEVV7kjafOooVQwSdZQ18ukQ2; 5:UjrAc0dNJby6snJmeNQyiXIFyTM9zzOKER//9pBBqTrSl6sw8BHUKx3Q+mHSkOggwfRESk4kSR0JYcayGwTCMu5Oc/i6F8dIZiVgQbl53Di6h7uksNLLXDp1Ep5PAF7IB4G7vNzWjV+6NSSIKvw1tY3jhsCcC00J5zJREZ3wyIk=; 24:SlMmEW5VZsI47yJs+IUBdnWzgs5/K6DfuwqwtFQAlzYILT6GpPzzbj8QkCiTKDhjaa1/BGGSI3VQWJd8cW4Pst03OZFaUK6BGc2uepYwH74=; 7:wQwUxW1Kbmc+GOgr+ePYUOqDiswAM982O+N4N3JmGUYORcMkC9L/Xuz2XJz4yMVZgWTz5d5RjVcP4XAEg5QloIWlAHfjoeTbqRjSlc0O+yc+uLQhRVObwIYcZpuhLH3AN4FT7rqMruyLO89f5GmYftxb0gVMvVi3boBIOZYSxWlzXY/5NLTrdyw1w/tD9x7aT7mhwU51ymJ/HNz//J95T/RxGW39imTdWovQhmxj5GuYDlHduJK+MbBoQEVHA+iRzv8BqTsyIrMjM+lLqiZj5WGh0tOTvMukVS15kzEtxV7NlHCEIHjt0ND5CrtLaaBiiqelAhTqvrPVf+ddmwg9TPZOlaf7yuR/jtQJwf4xKQk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0635; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(13464003)(199003)(189002)(87936001)(19580405001)(4326007)(68736007)(122556002)(2906002)(93886004)(33656002)(76576001)(305945005)(66066001)(10400500002)(106356001)(11100500001)(106116001)(99286002)(105586002)(92566002)(3280700002)(5001770100001)(97736004)(81166006)(102836003)(3846002)(8676002)(101416001)(81156014)(2900100001)(54356999)(50986999)(6116002)(3660700001)(189998001)(586003)(19580395003)(76176999)(5002640100001)(2950100002)(5660300001)(74316002)(8936002)(2171001)(7736002)(9686002)(7696004)(7846002)(31430400001)(86362001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 19:34:10.7585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-OriginatorOrg: fcc.gov Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 19:34:18 -0000 There are two scenarios, as you state: * Pre-call: For example, the Call-Info header in my other draft or CNAM ("C= ardholder Serv") lead the called party to hit the "spam" button before pick= ing up. This yields a 666 response to the INVITE. * Mid-call: The called party picks up, listens for 10 seconds, decides they= don't need "Microsoft" technical support, and hits the same spam button. = Signaled via BYE with Reason 666. Just like for email spam, the effect is two-fold, as noted: (1) I don't want this particular caller to reach me again. (2) Increment the bad reputation score for the caller. I don't see this response affecting a whole category of calls. For example,= I may decide that I really don't like the Police Benevolence Association c= all I just received, but that does not necessarily mean that I'd like to bl= ock the American Heart Association. I think category-based blocking is goin= g to be set up via a more sophisticated web mechanism that allows finer gra= ined controls ("No charities after 6 pm; only charities with a Charity Navi= gator rating of A"). Same for political calls - I may want to receive the t= own hall calls from the politician I like and never again hear from the one= I don't. Spoofing obviously makes call blocking of any sort more problematic, but mu= ch spoofing is from numbers that would never call me. For example, blocking= the "IRS" doesn't prevent the real IRS from calling me - they don't use th= e 800# (800-TAX-1040) for outbound calls. For now, many robocallers don't spoof since they want you to call back, giv= en that many people let unknown callers go to voicemail. But we've had versions of this discussion in STIR for several years. Henning -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, October 12, 2016 3:18 PM To: Asveren, Tolga Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts On 10/12/16 9:59 AM, Asveren, Tolga wrote: > Overall, I am in favor of keeping the utility/scope limited to "spam". Ju= st to list a few points along those lines: > > i- "666" would indicate that the user considers the call as spam/robocall= /annoyance; bottomline being that the user would prefer not to receive call= s originating from the same identity. While this seems reasonable, how will it work in practice? IOW, when will I= know to use it? If I use it before I answer the call, then on what basis am I doing so?=20 Is it because I recognize the number? Or is it based on the classification = assigned by the provider that has been displayed to me? Will I have an option to use it after I have answered the call? (As an alte= rnative to normal hangup.) If so, and if I do so then based on the content = of the call, is the meaning "would prefer not to receive calls originating = from the same identity"? I suspect it is really more "would prefer not to r= eceive calls of this type", regardless of the callerid.=20 (Especially when spam often comes from forged IDs.) These are two different semantics. Perhaps they can share the same code, si= nce they can be distinguished because they are signaled in different ways. = But it would be cleaner if they were different codes. > ii- "666" is not intended to be used for the user to blacklist his mother= -in-law. That -already- could be done by other means. > iii- "666" does not automatically blacklists the number/originating ident= ity. It is an input for a spam-blocker service, which possibly can be provi= ded by a SP. It also would be an input for a centralized robocall/spam logi= c, which possibly is used by multiple SPs and maybe administrated by a nati= onal authority. > iv- Actual blacklisting rules/service is something to be decided/provided= by the SP. This, for example, may include other components like a web-inte= rface accessible by users. SP may also provide "likely to be spam" (and sim= ilar) indicators for calls depending on existing analysis. I agree these seem like wise policies. > v- Consider the above points, I think a 6xx response is the right choice = and no 4xx response needs to be added/used. I'm neutral on this. > vi- SP/Central Authority may perform further analysis for a call, which h= as been rejected with "666", e.g. based on CDRs, logs, existing peering rel= ationships etc... And statistics. If the same calling number has been flagged by many users *after* they have= answered the call, then we can infer that there is a consistent behavior o= f bad behavior from this ID. That is worth investigating. If the same number has been flagged by many users *before* they have answer= ed the call, but not corroborated by others flagging it after answering, th= en the situation is unclear. Perhaps this number carries a calling name tha= t leads people to reject it? Or perhaps it is a number that is special enou= gh to be recognized by a lot of people. I think this would need to be inves= tigated carefully to understand what is going on. Thanks, Paul From nobody Wed Oct 12 13:00:38 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A97D12957B for ; Wed, 12 Oct 2016 13:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 LjDASntGHMZj for ; Wed, 12 Oct 2016 13:00:34 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35531294D0 for ; Wed, 12 Oct 2016 13:00:33 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-07v.sys.comcast.net with SMTP id uPgzboOzkff8quPhZbAeEp; Wed, 12 Oct 2016 20:00:33 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-18v.sys.comcast.net with SMTP id uPhXbuSndPns2uPhYbxi5f; Wed, 12 Oct 2016 20:00:32 +0000 To: Henning Schulzrinne , "Asveren, Tolga" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> From: Paul Kyzivat Message-ID: <59f4ffb9-1ad6-95da-d75a-b6b8721712ee@alum.mit.edu> Date: Wed, 12 Oct 2016 16:00:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHMpAEDEe/nHhpOIWBMudUKpWyzYy5DgZd/tVHWfUvuVjRLmpg8ixhvMhk4Y4I1X96adDZHFENEo8WX+NdgMH4zhvf4CnceELpvp9+WrnPLAM6pC6Tfm UVRcf71HWabwJEufDXTdIbnfw+KoEycdOIEfl3T9OFFbq1FmG0I+eSoktaBnM3GgYvLqhUquzbChPNKxPk6lz/1oSt+7HzUhMFygrR4vcUl6NZdsc2kt2Vcm J3S95aNutYL0QzgA/pgJTg== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 20:00:36 -0000 Henning, I mostly agree, with some qualifications, inline. On 10/12/16 3:34 PM, Henning Schulzrinne wrote: > There are two scenarios, as you state: > > * Pre-call: For example, the Call-Info header in my other draft or CNAM ("Cardholder Serv") lead the called party to hit the "spam" button before picking up. This yields a 666 response to the INVITE. > > * Mid-call: The called party picks up, listens for 10 seconds, decides they don't need "Microsoft" technical support, and hits the same spam button. Signaled via BYE with Reason 666. > > Just like for email spam, the effect is two-fold, as noted: > > (1) I don't want this particular caller to reach me again. > (2) Increment the bad reputation score for the caller. Trying to use the same signal to trigger both of these effects presents some issues. And I think they differ for Pre-call and mid-call? (1) seems appropriate for pre-call. It is clear that I am making a judgement based on the identity of the caller. Not so clear for mid-call. I definitely don't like the content, but that may or may not correlate to the caller identity. Risky to block the caller based on just this. (2) This action might be appropriate for both pre-call and mid-call, but the two types should probably be tallied separately and evaluated differently. For mid-call I am objecting to the content and the tally is used to see if the number has a history of bad content. For pre-call we really don't know what the callee is objecting to. Still worth tracking, but not as strong a measure. Of course we aren't standardizing this behavior, so discussing it is just for context. My bottom line here is just that it is hard to characterize the meaning of the code in a phrase. So I suggest using something quite vague, like "Objectionable" without qualification as to whether it is the calling id, calling name, content, or whatever that it applies to. The text description can go into more detail. But ultimately the meaning will be determined by others so we should be vague enough to cover whatever they decide to do. Thanks, Paul > I don't see this response affecting a whole category of calls. For example, I may decide that I really don't like the Police Benevolence Association call I just received, but that does not necessarily mean that I'd like to block the American Heart Association. I think category-based blocking is going to be set up via a more sophisticated web mechanism that allows finer grained controls ("No charities after 6 pm; only charities with a Charity Navigator rating of A"). Same for political calls - I may want to receive the town hall calls from the politician I like and never again hear from the one I don't. > > Spoofing obviously makes call blocking of any sort more problematic, but much spoofing is from numbers that would never call me. For example, blocking the "IRS" doesn't prevent the real IRS from calling me - they don't use the 800# (800-TAX-1040) for outbound calls. > > For now, many robocallers don't spoof since they want you to call back, given that many people let unknown callers go to voicemail. > > But we've had versions of this discussion in STIR for several years. > > Henning > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, October 12, 2016 3:18 PM > To: Asveren, Tolga > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > On 10/12/16 9:59 AM, Asveren, Tolga wrote: >> Overall, I am in favor of keeping the utility/scope limited to "spam". Just to list a few points along those lines: >> >> i- "666" would indicate that the user considers the call as spam/robocall/annoyance; bottomline being that the user would prefer not to receive calls originating from the same identity. > > While this seems reasonable, how will it work in practice? IOW, when will I know to use it? > > If I use it before I answer the call, then on what basis am I doing so? > Is it because I recognize the number? Or is it based on the classification assigned by the provider that has been displayed to me? > > Will I have an option to use it after I have answered the call? (As an alternative to normal hangup.) If so, and if I do so then based on the content of the call, is the meaning "would prefer not to receive calls originating from the same identity"? I suspect it is really more "would prefer not to receive calls of this type", regardless of the callerid. > (Especially when spam often comes from forged IDs.) > > These are two different semantics. Perhaps they can share the same code, since they can be distinguished because they are signaled in different ways. But it would be cleaner if they were different codes. > >> ii- "666" is not intended to be used for the user to blacklist his mother-in-law. That -already- could be done by other means. >> iii- "666" does not automatically blacklists the number/originating identity. It is an input for a spam-blocker service, which possibly can be provided by a SP. It also would be an input for a centralized robocall/spam logic, which possibly is used by multiple SPs and maybe administrated by a national authority. >> iv- Actual blacklisting rules/service is something to be decided/provided by the SP. This, for example, may include other components like a web-interface accessible by users. SP may also provide "likely to be spam" (and similar) indicators for calls depending on existing analysis. > > I agree these seem like wise policies. > >> v- Consider the above points, I think a 6xx response is the right choice and no 4xx response needs to be added/used. > > I'm neutral on this. > >> vi- SP/Central Authority may perform further analysis for a call, which has been rejected with "666", e.g. based on CDRs, logs, existing peering relationships etc... > > And statistics. > > If the same calling number has been flagged by many users *after* they have answered the call, then we can infer that there is a consistent behavior of bad behavior from this ID. That is worth investigating. > > If the same number has been flagged by many users *before* they have answered the call, but not corroborated by others flagging it after answering, then the situation is unclear. Perhaps this number carries a calling name that leads people to reject it? Or perhaps it is a number that is special enough to be recognized by a lot of people. I think this would need to be investigated carefully to understand what is going on. > > Thanks, > Paul > > > From nobody Thu Oct 13 05:12:48 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E8D1294BE for ; Thu, 13 Oct 2016 05:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 lT46Xp-YZ493 for ; Thu, 13 Oct 2016 05:12:43 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CFB129567 for ; Thu, 13 Oct 2016 05:12:42 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u9DC5fYa005690; Thu, 13 Oct 2016 08:12:39 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 261yttu7a0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 Oct 2016 08:12:39 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9DCCb8A003330; Thu, 13 Oct 2016 08:12:38 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u9DCCSCZ003199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Oct 2016 08:12:30 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 13 Oct 2016 12:12:18 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.163]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0301.000; Thu, 13 Oct 2016 08:12:18 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat , Henning Schulzrinne , "Asveren, Tolga" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWi2HwzrKjG+EiQ+j755/EMs6CdbouAgAADqYCAAAX3AIAAA40AgAAIxgCAATkyAIAABDwAgAA/vgCAAOR1QIAB6RiAgAMM3ECAAKA/AIAABKYAgAAHXICAAMla4A== Date: Thu, 13 Oct 2016 12:12:17 +0000 Message-ID: References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> <59f4ffb9-1ad6-95da-d75a-b6b8721712ee@alum.mit.edu> In-Reply-To: <59f4ffb9-1ad6-95da-d75a-b6b8721712ee@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.241.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610130209 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:12:46 -0000 I would see the treatment in the network to be slightly different between r= eceiving a pre versus mid call 666 response. Both would be fed into data analytics. Pre 666 would be used for the individual profile (possibly adding number to= a blacklist), and used in the data analytics for further analysis with oth= er calls to other users. Post 666 would initiate the reporting and traceback processes. Regards, Martin -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, October 12, 2016 4:01 PM To: Henning Schulzrinne ; Asveren, Tolga Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts Henning, I mostly agree, with some qualifications, inline. On 10/12/16 3:34 PM, Henning Schulzrinne wrote: > There are two scenarios, as you state: > > * Pre-call: For example, the Call-Info header in my other draft or CNAM (= "Cardholder Serv") lead the called party to hit the "spam" button before pi= cking up. This yields a 666 response to the INVITE. > > * Mid-call: The called party picks up, listens for 10 seconds, decides th= ey don't need "Microsoft" technical support, and hits the same spam button.= Signaled via BYE with Reason 666. > > Just like for email spam, the effect is two-fold, as noted: > > (1) I don't want this particular caller to reach me again. > (2) Increment the bad reputation score for the caller. Trying to use the same signal to trigger both of these effects presents som= e issues. And I think they differ for Pre-call and mid-call? (1) seems appropriate for pre-call. It is clear that I am making a judgemen= t based on the identity of the caller. Not so clear for mid-call. I definit= ely don't like the content, but that may or may not correlate to the caller= identity. Risky to block the caller based on just this. (2) This action might be appropriate for both pre-call and mid-call, but th= e two types should probably be tallied separately and evaluated differently= . For mid-call I am objecting to the content and the tally is used to see i= f the number has a history of bad content. For pre-call we really don't kno= w what the callee is objecting to. Still worth tracking, but not as strong = a measure. Of course we aren't standardizing this behavior, so discussing it is just f= or context. My bottom line here is just that it is hard to characterize the meaning of = the code in a phrase. So I suggest using something quite vague, like "Objec= tionable" without qualification as to whether it is the calling id, calling= name, content, or whatever that it applies to. The text description can go= into more detail. But ultimately the meaning will be determined by others = so we should be vague enough to cover whatever they decide to do. Thanks, Paul > I don't see this response affecting a whole category of calls. For exampl= e, I may decide that I really don't like the Police Benevolence Association= call I just received, but that does not necessarily mean that I'd like to = block the American Heart Association. I think category-based blocking is go= ing to be set up via a more sophisticated web mechanism that allows finer g= rained controls ("No charities after 6 pm; only charities with a Charity Na= vigator rating of A"). Same for political calls - I may want to receive the= town hall calls from the politician I like and never again hear from the o= ne I don't. > > Spoofing obviously makes call blocking of any sort more problematic, but = much spoofing is from numbers that would never call me. For example, blocki= ng the "IRS" doesn't prevent the real IRS from calling me - they don't use = the 800# (800-TAX-1040) for outbound calls. > > For now, many robocallers don't spoof since they want you to call back, g= iven that many people let unknown callers go to voicemail. > > But we've had versions of this discussion in STIR for several years. > > Henning > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20 > Kyzivat > Sent: Wednesday, October 12, 2016 3:18 PM > To: Asveren, Tolga > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > On 10/12/16 9:59 AM, Asveren, Tolga wrote: >> Overall, I am in favor of keeping the utility/scope limited to "spam". J= ust to list a few points along those lines: >> >> i- "666" would indicate that the user considers the call as spam/robocal= l/annoyance; bottomline being that the user would prefer not to receive cal= ls originating from the same identity. > > While this seems reasonable, how will it work in practice? IOW, when will= I know to use it? > > If I use it before I answer the call, then on what basis am I doing so? > Is it because I recognize the number? Or is it based on the classificatio= n assigned by the provider that has been displayed to me? > > Will I have an option to use it after I have answered the call? (As an al= ternative to normal hangup.) If so, and if I do so then based on the conten= t of the call, is the meaning "would prefer not to receive calls originatin= g from the same identity"? I suspect it is really more "would prefer not to= receive calls of this type", regardless of the callerid. > (Especially when spam often comes from forged IDs.) > > These are two different semantics. Perhaps they can share the same code, = since they can be distinguished because they are signaled in different ways= . But it would be cleaner if they were different codes. > >> ii- "666" is not intended to be used for the user to blacklist his mothe= r-in-law. That -already- could be done by other means. >> iii- "666" does not automatically blacklists the number/originating iden= tity. It is an input for a spam-blocker service, which possibly can be prov= ided by a SP. It also would be an input for a centralized robocall/spam log= ic, which possibly is used by multiple SPs and maybe administrated by a nat= ional authority. >> iv- Actual blacklisting rules/service is something to be decided/provide= d by the SP. This, for example, may include other components like a web-int= erface accessible by users. SP may also provide "likely to be spam" (and si= milar) indicators for calls depending on existing analysis. > > I agree these seem like wise policies. > >> v- Consider the above points, I think a 6xx response is the right choice= and no 4xx response needs to be added/used. > > I'm neutral on this. > >> vi- SP/Central Authority may perform further analysis for a call, which = has been rejected with "666", e.g. based on CDRs, logs, existing peering re= lationships etc... > > And statistics. > > If the same calling number has been flagged by many users *after* they ha= ve answered the call, then we can infer that there is a consistent behavior= of bad behavior from this ID. That is worth investigating. > > If the same number has been flagged by many users *before* they have answ= ered the call, but not corroborated by others flagging it after answering, = then the situation is unclear. Perhaps this number carries a calling name t= hat leads people to reject it? Or perhaps it is a number that is special en= ough to be recognized by a lot of people. I think this would need to be inv= estigated carefully to understand what is going on. > > Thanks, > Paul > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Oct 13 06:45:55 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AED12979F for ; Thu, 13 Oct 2016 06:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 qFPmp68EZ0Sn for ; Thu, 13 Oct 2016 06:45:51 -0700 (PDT) Received: from email1.corp.yaanatech.com (12-229-59-67-static.dzbja.com [12.229.59.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2301297B7 for ; Thu, 13 Oct 2016 06:45:48 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 13 Oct 2016 06:45:48 -0700 From: Michael Hammer To: "md3135@att.com" , "pkyzivat@alum.mit.edu" , "Henning.Schulzrinne@fcc.gov" , "tasveren@sonusnet.com" Thread-Topic: [dispatch] Two new VoIP spam drafts Thread-Index: AQHSIKWizkv0CY4240OFBNqXtqGVyKCd4+SAgAADqYCAAAX3AIAAA40AgAAIxgCAATkxAIAABD0AgAA/vQCAAOXUgIAB57qAgAMROoCAAFjTAIAABKUAgAAHXYCAAQ+CgP//omlA Date: Thu, 13 Oct 2016 13:45:47 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BD040A33@sc9-ex2k10mb1.corp.yaanatech.com> References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> <59f4ffb9-1ad6-95da-d75a-b6b8721712ee@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.127] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0029_01D22536.9247B3C0" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 13:45:54 -0000 ------=_NextPart_000_0029_01D22536.9247B3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In addition, it might be necessary to cross-correlate the pre- and = mid-call data. It could very well turn out that the first call is answered and = rejected, and the second call is rejected pre-call, but the user has figured out = that the presented information (e.g. what happens if both numbers show up = with the same or similar user name and business names and timing?) for the = second call is likely same as the first number? Could be some non-artificial intelligence going on here. Bottom line, the customer may recognize porn, I mean spam when he sees = it. And the customer is always right. :) Just keep in mind that this is all fuzzy, crowd-sourced information. No one call may have wider impact than another. ________________________________ Michael Hammer michael.hammer@yaanatech.com +1=A0408 202 9291 =A9 2016 Yaana Technologies, LLC. All Rights Reserved. Email = confidentiality notice. This message is private and confidential. If you have received = this message in error, please notify us and remove it from your system. -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, = MARTIN C Sent: Thursday, October 13, 2016 8:12 AM To: Paul Kyzivat ; Henning Schulzrinne ; Asveren, Tolga Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts I would see the treatment in the network to be slightly different = between receiving a pre versus mid call 666 response. Both would be fed into data analytics. Pre 666 would be used for the individual profile (possibly adding number = to a blacklist), and used in the data analytics for further analysis with = other calls to other users. Post 666 would initiate the reporting and traceback processes. Regards, Martin -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul = Kyzivat Sent: Wednesday, October 12, 2016 4:01 PM To: Henning Schulzrinne ; Asveren, Tolga Cc: dispatch@ietf.org Subject: Re: [dispatch] Two new VoIP spam drafts Henning, I mostly agree, with some qualifications, inline. On 10/12/16 3:34 PM, Henning Schulzrinne wrote: > There are two scenarios, as you state: > > * Pre-call: For example, the Call-Info header in my other draft or = CNAM ("Cardholder Serv") lead the called party to hit the "spam" button = before picking up. This yields a 666 response to the INVITE. > > * Mid-call: The called party picks up, listens for 10 seconds, decides they don't need "Microsoft" technical support, and hits the same spam button. Signaled via BYE with Reason 666. > > Just like for email spam, the effect is two-fold, as noted: > > (1) I don't want this particular caller to reach me again. > (2) Increment the bad reputation score for the caller. Trying to use the same signal to trigger both of these effects presents = some issues. And I think they differ for Pre-call and mid-call? (1) seems appropriate for pre-call. It is clear that I am making a = judgement based on the identity of the caller. Not so clear for mid-call. I = definitely don't like the content, but that may or may not correlate to the caller identity. Risky to block the caller based on just this. (2) This action might be appropriate for both pre-call and mid-call, but = the two types should probably be tallied separately and evaluated = differently. For mid-call I am objecting to the content and the tally is used to see = if the number has a history of bad content. For pre-call we really don't = know what the callee is objecting to. Still worth tracking, but not as strong = a measure. Of course we aren't standardizing this behavior, so discussing it is = just for context. My bottom line here is just that it is hard to characterize the meaning = of the code in a phrase. So I suggest using something quite vague, like "Objectionable" without qualification as to whether it is the calling = id, calling name, content, or whatever that it applies to. The text = description can go into more detail. But ultimately the meaning will be determined = by others so we should be vague enough to cover whatever they decide to do. Thanks, Paul > I don't see this response affecting a whole category of calls. For example, I may decide that I really don't like the Police Benevolence Association call I just received, but that does not necessarily mean = that I'd like to block the American Heart Association. I think category-based blocking is going to be set up via a more sophisticated web mechanism = that allows finer grained controls ("No charities after 6 pm; only charities = with a Charity Navigator rating of A"). Same for political calls - I may want = to receive the town hall calls from the politician I like and never again = hear from the one I don't. > > Spoofing obviously makes call blocking of any sort more problematic, = but much spoofing is from numbers that would never call me. For example, blocking the "IRS" doesn't prevent the real IRS from calling me - they = don't use the 800# (800-TAX-1040) for outbound calls. > > For now, many robocallers don't spoof since they want you to call = back, given that many people let unknown callers go to voicemail. > > But we've had versions of this discussion in STIR for several years. > > Henning > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul=20 > Kyzivat > Sent: Wednesday, October 12, 2016 3:18 PM > To: Asveren, Tolga > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > On 10/12/16 9:59 AM, Asveren, Tolga wrote: >> Overall, I am in favor of keeping the utility/scope limited to = "spam". Just to list a few points along those lines: >> >> i- "666" would indicate that the user considers the call as spam/robocall/annoyance; bottomline being that the user would prefer not = to receive calls originating from the same identity. > > While this seems reasonable, how will it work in practice? IOW, when = will I know to use it? > > If I use it before I answer the call, then on what basis am I doing = so? > Is it because I recognize the number? Or is it based on the = classification assigned by the provider that has been displayed to me? > > Will I have an option to use it after I have answered the call? (As an alternative to normal hangup.) If so, and if I do so then based on the content of the call, is the meaning "would prefer not to receive calls originating from the same identity"? I suspect it is really more "would prefer not to receive calls of this type", regardless of the callerid. > (Especially when spam often comes from forged IDs.) > > These are two different semantics. Perhaps they can share the same = code, since they can be distinguished because they are signaled in different = ways. But it would be cleaner if they were different codes. > >> ii- "666" is not intended to be used for the user to blacklist his mother-in-law. That -already- could be done by other means. >> iii- "666" does not automatically blacklists the number/originating identity. It is an input for a spam-blocker service, which possibly can = be provided by a SP. It also would be an input for a centralized = robocall/spam logic, which possibly is used by multiple SPs and maybe administrated by = a national authority. >> iv- Actual blacklisting rules/service is something to be = decided/provided by the SP. This, for example, may include other components like a web-interface accessible by users. SP may also provide "likely to be = spam" (and similar) indicators for calls depending on existing analysis. > > I agree these seem like wise policies. > >> v- Consider the above points, I think a 6xx response is the right = choice and no 4xx response needs to be added/used. > > I'm neutral on this. > >> vi- SP/Central Authority may perform further analysis for a call, = which has been rejected with "666", e.g. based on CDRs, logs, existing peering relationships etc... > > And statistics. > > If the same calling number has been flagged by many users *after* they have answered the call, then we can infer that there is a consistent behavior of bad behavior from this ID. That is worth investigating. > > If the same number has been flagged by many users *before* they have answered the call, but not corroborated by others flagging it after answering, then the situation is unclear. Perhaps this number carries a calling name that leads people to reject it? Or perhaps it is a number = that is special enough to be recognized by a lot of people. I think this = would need to be investigated carefully to understand what is going on. > > Thanks, > Paul > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_0029_01D22536.9247B3C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhBMAzfzqk7mKu8vbItErxUIMA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MDIyOTAwMDAwMFoXDTE4MDIyODIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWEk4s5ORfNfQ/oXDD k4mHDQDDpO3s2oEy7055JdLoleNQXEJGsv8EsqPagYul55uVZ57tmx2H1LjM6QfD7N821joisKa4 +l92JImsffrTnll8gxJ9VV9/WmGpPWwFg4ipw3qRdDhQJnQiNKzlqPMSIDE76uhrKv3hYE30tVIO R8U9erAprCBoHd2Ch1+pIGlFjl91//BR1sehnJR9Z1gZHMEqjto/jYPR1uEapueR6W+YuL9O9HmW RLA925xiZmzwKqB8HS0wG+PjLnMRnohdIh4e+/FKWksC82rP7vmP3SHOzQKdgdapaavCTx/1ZYiR N6cMT95ZCgB1aHXR1lCfAgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQBX iSRv04vVx/Y5lWWITUJhWXUTnhM70UUqIEinNF+cV9+zY0lomYqoB8ovCfWrvx232tzX86NtreSn 9UjhBRj61oqSyK9v6P14dunX1MjRZmOVeKws3+XDS3NPsopui5YOPjSy02qhyVN4tIDCokj71db1 wO7uZ/DehNWkwFUgMKdVKM5LAGIDHgWn2dvzGi+ipdDNjMD2SxMnCSOiZ3z9gh/Yy+flNaXn5vLL O0AJEW5xCl2tbuPh/DghqlaiVeCLaCar3cj2Ka6ew5wRhNpvmno47b0C5w6JDxx++ijXjGPzYr57 J8QvCDs9f3Cn5doEF3bTQmcab+s3VEgIhAt1MYIE4zCCBN8CAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwCQYFKw4DAhoFAKCCAtkwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDEzMTM0NTQ1WjAjBgkqhkiG 9w0BCQQxFgQUhAzQfwDeAIsOJq00ZVNfHQ9reuAwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglg hkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5 bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UE AxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJtZWRpYXRlIENlcnRpZmljYXRlIEF1dGhv cml0eQIQTAM386pO5irvL2yLRK8VCDCB8QYLKoZIhvcNAQkQAgsxgeGggd4wgckxCzAJBgNVBAYT AlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1 c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNj cmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBD ZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEwDN/OqTuYq7y9si0SvFQgwDQYJKoZIhvcNAQEBBQAEggEA U+jPU1E0kCdDyXryqCaRoZQCHslwV5nq0QUgUjlb+H1QlPGBad/69B84NwO+Q+B0zIwowgw/yrrl 7dao1LTBJj2ru27jLsxX7h0CZbnPJI8pReKYbILnJhJqZB4hwhX3QtbkJ8uUrq8LokJSSVJMXtOK tnPfysGICCv3GToaicmeXXrt/H+mS5tGwNTvovIeC/E6M+7qpYHOe29hgoRMdZy2D4nb19Yki2ZX CWQWZjy8nClIAruSJliTJi1j7axYyRK5tuM7/BKu1O3Z2Or2ZjrZ3z2jRw3B3lxZT6GB27kkHiNH wL4bcpKwd371Ag5mtiULUcTsxI6PfLHeAFr63wAAAAAAAA== ------=_NextPart_000_0029_01D22536.9247B3C0-- From nobody Thu Oct 13 09:22:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02FD12952E for ; Thu, 13 Oct 2016 09:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no 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 PORi2bm6qsAP for ; Thu, 13 Oct 2016 09:22:33 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B326127A91 for ; Thu, 13 Oct 2016 09:22:33 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-01v.sys.comcast.net with SMTP id uilgbehIBTaLwuim8bLTN6; Thu, 13 Oct 2016 16:22:32 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-09v.sys.comcast.net with SMTP id uim6b2qhr0vPtuim7b7daJ; Thu, 13 Oct 2016 16:22:32 +0000 To: Michael Hammer , "md3135@att.com" , "Henning.Schulzrinne@fcc.gov" , "tasveren@sonusnet.com" References: <87y4205jkr.fsf@hobgoblin.ariadne.com> <0C68C1B9-9169-4F62-8D78-D233BD0CA8E4@shockey.us> <77a1e836-a6f2-6777-62f1-45a32f067647@alum.mit.edu> <18576a53-1491-6847-a324-82f8cacf1863@alum.mit.edu> <59f4ffb9-1ad6-95da-d75a-b6b8721712ee@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BD040A33@sc9-ex2k10mb1.corp.yaanatech.com> From: Paul Kyzivat Message-ID: <4252706f-e197-ed67-e838-ac82d7d5e2d3@alum.mit.edu> Date: Thu, 13 Oct 2016 12:22:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BD040A33@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNaDi/Cgabdv92YqBs2jKvbmFEnqujhT3j+tIJhIydUD1tMAOLw/GYkE5xYyds8Q19ryuHUpX4uwcdwxPbzv8cDpFwcMesWCBqGDUyM4m8cIoQE4NAJv hpXjNhwjVIVrpJKw9Hdbkgtswiz1MAw8JMvBHPVsMaejt03+Ke3oU7ZEpn9jBZYm2pkBme3WW/ZBWfCSNKixjpGVJC60o89bQswfkhM8ElGtIkGz+xgboo5t HviODAXcQP9RYGyMURW9nVu85sYvHBbEWRDL3A/n1wyHwar1ec55lNJ+b8de/QJx20KgK7Oe6p24YpARLq263g== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Two new VoIP spam drafts X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 16:22:36 -0000 On 10/13/16 9:45 AM, Michael Hammer wrote: > In addition, it might be necessary to cross-correlate the pre- and mid-call > data. > > It could very well turn out that the first call is answered and rejected, > and the second call is rejected pre-call, but the user has figured out that > the presented information (e.g. what happens if both numbers show up with > the same or similar user name and business names and timing?) for the second > call is likely same as the first number? > Could be some non-artificial intelligence going on here. +1 > Bottom line, the customer may recognize porn, I mean spam when he sees it. > And the customer is always right. :) > > Just keep in mind that this is all fuzzy, crowd-sourced information. > No one call may have wider impact than another. > > ________________________________ > Michael Hammer > michael.hammer@yaanatech.com > +1 408 202 9291 > > 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality > notice. This message is private and confidential. If you have received this > message in error, please notify us and remove it from your system. > > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DOLLY, MARTIN > C > Sent: Thursday, October 13, 2016 8:12 AM > To: Paul Kyzivat ; Henning Schulzrinne > ; Asveren, Tolga > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > I would see the treatment in the network to be slightly different between > receiving a pre versus mid call 666 response. > > Both would be fed into data analytics. > Pre 666 would be used for the individual profile (possibly adding number to > a blacklist), and used in the data analytics for further analysis with other > calls to other users. > Post 666 would initiate the reporting and traceback processes. > > Regards, > > Martin > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, October 12, 2016 4:01 PM > To: Henning Schulzrinne ; Asveren, Tolga > > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Two new VoIP spam drafts > > Henning, > > I mostly agree, with some qualifications, inline. > > On 10/12/16 3:34 PM, Henning Schulzrinne wrote: >> There are two scenarios, as you state: >> >> * Pre-call: For example, the Call-Info header in my other draft or CNAM > ("Cardholder Serv") lead the called party to hit the "spam" button before > picking up. This yields a 666 response to the INVITE. >> >> * Mid-call: The called party picks up, listens for 10 seconds, decides > they don't need "Microsoft" technical support, and hits the same spam > button. Signaled via BYE with Reason 666. >> >> Just like for email spam, the effect is two-fold, as noted: >> >> (1) I don't want this particular caller to reach me again. >> (2) Increment the bad reputation score for the caller. > > Trying to use the same signal to trigger both of these effects presents some > issues. And I think they differ for Pre-call and mid-call? > > (1) seems appropriate for pre-call. It is clear that I am making a judgement > based on the identity of the caller. Not so clear for mid-call. I definitely > don't like the content, but that may or may not correlate to the caller > identity. Risky to block the caller based on just this. > > (2) This action might be appropriate for both pre-call and mid-call, but the > two types should probably be tallied separately and evaluated differently. > For mid-call I am objecting to the content and the tally is used to see if > the number has a history of bad content. For pre-call we really don't know > what the callee is objecting to. Still worth tracking, but not as strong a > measure. > > Of course we aren't standardizing this behavior, so discussing it is just > for context. > > My bottom line here is just that it is hard to characterize the meaning of > the code in a phrase. So I suggest using something quite vague, like > "Objectionable" without qualification as to whether it is the calling id, > calling name, content, or whatever that it applies to. The text description > can go into more detail. But ultimately the meaning will be determined by > others so we should be vague enough to cover whatever they decide to do. > > Thanks, > Paul > >> I don't see this response affecting a whole category of calls. For > example, I may decide that I really don't like the Police Benevolence > Association call I just received, but that does not necessarily mean that > I'd like to block the American Heart Association. I think category-based > blocking is going to be set up via a more sophisticated web mechanism that > allows finer grained controls ("No charities after 6 pm; only charities with > a Charity Navigator rating of A"). Same for political calls - I may want to > receive the town hall calls from the politician I like and never again hear > from the one I don't. >> >> Spoofing obviously makes call blocking of any sort more problematic, but > much spoofing is from numbers that would never call me. For example, > blocking the "IRS" doesn't prevent the real IRS from calling me - they don't > use the 800# (800-TAX-1040) for outbound calls. >> >> For now, many robocallers don't spoof since they want you to call back, > given that many people let unknown callers go to voicemail. >> >> But we've had versions of this discussion in STIR for several years. >> >> Henning >> >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: Wednesday, October 12, 2016 3:18 PM >> To: Asveren, Tolga >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] Two new VoIP spam drafts >> >> On 10/12/16 9:59 AM, Asveren, Tolga wrote: >>> Overall, I am in favor of keeping the utility/scope limited to "spam". > Just to list a few points along those lines: >>> >>> i- "666" would indicate that the user considers the call as > spam/robocall/annoyance; bottomline being that the user would prefer not to > receive calls originating from the same identity. >> >> While this seems reasonable, how will it work in practice? IOW, when will > I know to use it? >> >> If I use it before I answer the call, then on what basis am I doing so? >> Is it because I recognize the number? Or is it based on the classification > assigned by the provider that has been displayed to me? >> >> Will I have an option to use it after I have answered the call? (As an > alternative to normal hangup.) If so, and if I do so then based on the > content of the call, is the meaning "would prefer not to receive calls > originating from the same identity"? I suspect it is really more "would > prefer not to receive calls of this type", regardless of the callerid. >> (Especially when spam often comes from forged IDs.) >> >> These are two different semantics. Perhaps they can share the same code, > since they can be distinguished because they are signaled in different ways. > But it would be cleaner if they were different codes. >> >>> ii- "666" is not intended to be used for the user to blacklist his > mother-in-law. That -already- could be done by other means. >>> iii- "666" does not automatically blacklists the number/originating > identity. It is an input for a spam-blocker service, which possibly can be > provided by a SP. It also would be an input for a centralized robocall/spam > logic, which possibly is used by multiple SPs and maybe administrated by a > national authority. >>> iv- Actual blacklisting rules/service is something to be decided/provided > by the SP. This, for example, may include other components like a > web-interface accessible by users. SP may also provide "likely to be spam" > (and similar) indicators for calls depending on existing analysis. >> >> I agree these seem like wise policies. >> >>> v- Consider the above points, I think a 6xx response is the right choice > and no 4xx response needs to be added/used. >> >> I'm neutral on this. >> >>> vi- SP/Central Authority may perform further analysis for a call, which > has been rejected with "666", e.g. based on CDRs, logs, existing peering > relationships etc... >> >> And statistics. >> >> If the same calling number has been flagged by many users *after* they > have answered the call, then we can infer that there is a consistent > behavior of bad behavior from this ID. That is worth investigating. >> >> If the same number has been flagged by many users *before* they have > answered the call, but not corroborated by others flagging it after > answering, then the situation is unclear. Perhaps this number carries a > calling name that leads people to reject it? Or perhaps it is a number that > is special enough to be recognized by a lot of people. I think this would > need to be investigated carefully to understand what is going on. >> >> Thanks, >> Paul >> >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Oct 18 07:57:02 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E684612967F for ; Tue, 18 Oct 2016 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 xM44HpI8vXAs for ; Tue, 18 Oct 2016 07:54:31 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id BB4861294A7 for ; Tue, 18 Oct 2016 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1476802471; d=isode.com; s=june2016; i=@isode.com; bh=othpupY/bqJh8S5igcTi9UHqUm4CfUOHlF8UIq3V944=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=jqRAwmcu+mxa8UEqB+bTAWiSELcFdzb6Uw/Yi0aFowYhkzPtoZ0MyKzld0HxaY3SPvLPqu bwUTiqWNqoPLHE/BdSHqnEIL036lIxP4yT3Np/YgdaZOiY7jyOepH/7QmliZM9gvq+OWQn 2/WVqAJzkhg3Z4vD1mgBHXO+6sD+y0Q=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 18 Oct 2016 15:54:30 +0100 From: Alexey Melnikov Message-ID: Date: Tue, 18 Oct 2016 15:54:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 To: undisclosed-recipients: ; MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 18 Oct 2016 07:57:02 -0700 Subject: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 14:54:33 -0000 Hi, I received a request to form a new WG that will work on revising CBOR (RFC 7049), finishing CDDL and working on a couple of CBOR extensions. Please comment on the proposed charter and proposed work. --------- Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., COSE, GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL) is a proposal for such a description technique that has already been used successfully in COSE, GRASP, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an RFC that can be used as a normative reference in a protocol specification. In parallel to the work on CDDL, the WG will examine the Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG might complete these specifications as well. --------- Best Regards, Alexey, as an ART AD. From nobody Tue Oct 18 08:04:54 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F9C12968A for ; Tue, 18 Oct 2016 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 GjrEvHG_VtPy for ; Tue, 18 Oct 2016 08:04:53 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 811081294B5 for ; Tue, 18 Oct 2016 07:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1476802712; d=isode.com; s=june2016; i=@isode.com; bh=3fZfm6giysqpvKpuPX8V4ONiGq0H5GHKD9q9wxyVSjs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GJNFSYH0p/+9nkHKUgWREJ+p6UNSePPHCTFfBqC1yoBCjZQ8gWuF6FP9VScE5RLNJEnBaa dKi5BKEeH42ktHFTkq05ZTEdsjmYv+d2hQyE+mYTHKi6xkl7NoT3bnMMkXHa7LajHlY21x VHC+JUUvFJd37GuShN/esJs86ZM/EEg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 18 Oct 2016 15:58:32 +0100 From: Alexey Melnikov To: dispatch@ietf.org Message-ID: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> Date: Tue, 18 Oct 2016 15:58:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 15:04:54 -0000 Hi, I received a request to form a new WG that will work on revising CBOR (RFC 7049), finishing CDDL and working on a couple of CBOR extensions. Please comment on the proposed charter and proposed work. --------- Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., COSE, GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL) is a proposal for such a description technique that has already been used successfully in COSE, GRASP, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an RFC that can be used as a normative reference in a protocol specification. In parallel to the work on CDDL, the WG will examine the Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG might complete these specifications as well. --------- Best Regards, Alexey, as an ART AD. From nobody Tue Oct 18 13:48:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B130A12985C for ; Tue, 18 Oct 2016 13:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 yL0qLNY0x3k7 for ; Tue, 18 Oct 2016 13:48:55 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id E726F1295C6 for ; Tue, 18 Oct 2016 13:48:54 -0700 (PDT) X-AuditID: 12074412-abdff700000008d1-be-58068ab5d950 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.50.02257.5BA86085; Tue, 18 Oct 2016 16:48:54 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u9IKmqRG001233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Oct 2016 16:48:53 -0400 To: dispatch@ietf.org References: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> From: Paul Kyzivat Message-ID: <75163e85-c424-c960-7096-4cce18405199@alum.mit.edu> Date: Tue, 18 Oct 2016 16:48:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixO6iqLutiy3C4FE/n8XSSQtYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0b28l7lgqVBFw7lepgbGp3xdjJwcEgImEt9vXWQGsYUELjNK 7OqP6GLkArLfM0nc/zgRLCEsoC/x40YvC4gtIiAqMX/FInaIBhuJgxOOMoLYbAJaEnMO/Qer 4RWwl+jq2A4U5+BgEVCVWHBJDyQsKpAmsX3dbmaIEkGJkzOfgJVzCthKPLt8BGwkM5B9Zy5E DbOAvMT2t3OYJzDyzULSMgtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW6Zrp5WaW 6KWmlG5ihISY0A7G9SflDjEKcDAq8fB6WLNFCLEmlhVX5h5ilORgUhLlbfUGCvEl5adUZiQW Z8QXleakFh9ilOBgVhLh7e8AyvGmJFZWpRblw6SkOViUxHl/Llb3ExJITyxJzU5NLUgtgsnK cHAoSfCu6ARqFCxKTU+tSMvMKUFIM3FwggznARouAFLDW1yQmFucmQ6RP8WoKCXOewBkqwBI IqM0D64XlgJeMYoDvSLMuwaknQeYPuC6XwENZgIafC6PBWRwSSJCSqqBUYZzYZB/4Eal+L7j Z6uYp+5bcMdm6izhqebvhN80Xs+KD9phIJlzbjaPzMJpU198YBPl6KldfeDSnQvpX/of/Xpq qnrPRIFzlv/ZKU+dzU+1Vi9UWRosxB3zusGvhfGdgf4T7R8pT3hmbeOaF6AzlWdJnMKDOP3U uK1Ts5ceXhOeMPcR33QbeyWW4oxEQy3mouJEAIpE6BvcAgAA Archived-At: Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 20:48:57 -0000 Alexey, On 10/18/16 10:58 AM, Alexey Melnikov wrote: > Hi, > I received a request to form a new WG that will work on revising CBOR > (RFC 7049), finishing CDDL and working on a couple of CBOR extensions. > > Please comment on the proposed charter and proposed work. > > --------- > > Concise Binary Object Representation (CBOR, RFC 7049) extends the > JavaScript Object Notation (JSON, RFC 7159) data model to include binary > data and an extensibility model, using a binary representation format > that is easy to parse correctly. It has been picked up by a number of > IETF efforts (e.g., COSE, GRASP) as a message format. Is CBOR intended to simply be an alternative encoding for JSON? > The CBOR working group will update RFC 7049 to fix verified errata. > Security issues and clarifications may be addressed, but changes to the > document will ensure backward compatibility for popular deployed > codebases. The resulting document will be targeted at becoming an > Internet Standard. > > Similar to the way ABNF (RFC 5234/7405) can be used to describe the set > of valid messages in a text representation, it would be useful if > protocol specifications could use a description format for the data in > CBOR-encoded messages. The CBOR data definition language (CDDL) is a > proposal for such a description technique that has already been used > successfully in COSE, GRASP, and efforts outside the IETF. The CBOR WG > will complete the development of this specification by creating an RFC > that can be used as a normative reference in a protocol specification. ISTM it would be good if a single schema representation was applicable to both JSON and CBOR. Thanks, Paul > In parallel to the work on CDDL, the WG will examine the > Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid > that > use CBOR's extensibility mechanisms to provide additional data types as > used in certain applications. Where these proposals are deemed useful > and do not require significant new > development, the CBOR WG might complete these specifications as well. > --------- > > Best Regards, > Alexey, as an ART AD. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Oct 18 15:46:53 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196771294B7 for ; Tue, 18 Oct 2016 15:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 RHE6V0Ieu7rV for ; Tue, 18 Oct 2016 15:46:51 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA13E12947B for ; Tue, 18 Oct 2016 15:46:50 -0700 (PDT) Received: (qmail 43038 invoked from network); 18 Oct 2016 22:46:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 18 Oct 2016 22:46:49 -0000 Date: 18 Oct 2016 22:46:27 -0000 Message-ID: <20161018224627.27127.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: <75163e85-c424-c960-7096-4cce18405199@alum.mit.edu> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 22:46:52 -0000 >Is CBOR intended to simply be an alternative encoding for JSON? My recollection is that during the discussion of CBOR, the authors said rather firmly that although CBOR has obvious resemblances to JSON, it's not JSON. If you look at both of them, you can see that CBOR already has all sorts of stuff beyond is in JSON, such as a distinction between integer and floating point values, and semantic tags that let you say things like this string represents a date. Perhaps Paul and Carsten could clarify here. >ISTM it would be good if a single schema representation was applicable >to both JSON and CBOR. I see why one would want that, but given the existing semantic differences between JSON and CBOR, I doubt it's feasible. R's, John From nobody Tue Oct 18 15:57:34 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAD012947D for ; Tue, 18 Oct 2016 15:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 g_rJsv5ofXe2 for ; Tue, 18 Oct 2016 15:57:31 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46034129437 for ; Tue, 18 Oct 2016 15:57:31 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 87E6F22E255 for ; Tue, 18 Oct 2016 18:57:24 -0400 (EDT) To: dispatch@ietf.org References: <20161018224627.27127.qmail@ary.lan> From: Sean Leonard Message-ID: <8277aa12-4319-7726-29bc-d26077ff7e11@seantek.com> Date: Tue, 18 Oct 2016 15:57:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161018224627.27127.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 22:57:32 -0000 On 10/18/2016 3:46 PM, John Levine wrote: >> Is CBOR intended to simply be an alternative encoding for JSON? > My recollection is that during the discussion of CBOR, the authors > said rather firmly that although CBOR has obvious resemblances to > JSON, it's not JSON. If you look at both of them, you can see that > CBOR already has all sorts of stuff beyond is in JSON, such as a > distinction between integer and floating point values, and semantic > tags that let you say things like this string represents a date. > > Perhaps Paul and Carsten could clarify here. > >> ISTM it would be good if a single schema representation was applicable >> to both JSON and CBOR. > I see why one would want that, but given the existing semantic > differences between JSON and CBOR, I doubt it's feasible. John is correct. Additionally, it can be said that CBOR is a "superset" of JSON, in that the semantic content of JSON texts [RFC7159] are representable in native CBOR. "Possible" for a JSON+CBOR schema yes; "feasible" no. Additionally, JSON schema technology already exists.already. Best regards, Sean From nobody Tue Oct 18 17:36:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA7129446 for ; Tue, 18 Oct 2016 17:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] 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 alE6V5IIPvvh for ; Tue, 18 Oct 2016 17:36:04 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 96B631295A0 for ; Tue, 18 Oct 2016 17:35:56 -0700 (PDT) X-AuditID: 12074413-991ff70000000a14-4e-5806bfe735cd Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.BA.02580.7EFB6085; Tue, 18 Oct 2016 20:35:55 -0400 (EDT) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u9J0Zot0013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Oct 2016 20:35:51 -0400 To: dispatch@ietf.org References: <20161018224627.27127.qmail@ary.lan> <8277aa12-4319-7726-29bc-d26077ff7e11@seantek.com> From: Paul Kyzivat Message-ID: Date: Tue, 18 Oct 2016 20:35:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8277aa12-4319-7726-29bc-d26077ff7e11@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqPt6P1uEwaM+XoulkxawOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+U3qYKVXBX3tlxiamCcztHFyMkhIWAi8ev0cpYuRi4OIYHL jBK7biyAct4zSTxY+ZMFpEpYQF/ix41eMFtEQFRi/opF7CC2kECqxNoP11hBbDYBLYk5h/6D 1fAK2EvcXXuYDcRmEVCVaL/3nBHEFhVIk9i+bjczRI2gxMmZT8DqOYHqjx39BWYzC9hK3JkL UcMsIC+x/e0c5gmMfLOQtMxCUjYLSdkCRuZVjHKJOaW5urmJmTnFqcm6xcmJeXmpRbrmermZ JXqpKaWbGCFBJryDcddJuUOMAhyMSjy8HtZsEUKsiWXFlbmHGCU5mJREeQ9PBQrxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4T2+GyjHm5JYWZValA+TkuZgURLnVVui7ickkJ5YkpqdmlqQWgST leHgUJLg5QZGk5BgUWp6akVaZk4JQpqJgxNkOA/Q8Lv7QIYXFyTmFmemQ+RPMSpKifOmgyQE QBIZpXlwvbAk8IpRHOgVYd42kCoeYAKB634FNJgJaPC5PBaQwSWJCCmpBsZ6+/evDs6+V/Xf MsLr6tVzQltenlx+jaG91IVDKkVads2F3s7COYbFrk8V/25/3f+jsDu1w4n/uE7kbt2lK25X WOaIlTy6ev5cVYG9/MPfNi6szSaMqkpFN2Yz8D5zWpO76v7dR3+LXVr4VgstPr9O4XftxCuP f++oKznVLvProtSuOCUPCVclluKMREMt5qLiRACx6Bwe3QIAAA== Archived-At: Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 00:36:07 -0000 On 10/18/16 6:57 PM, Sean Leonard wrote: > On 10/18/2016 3:46 PM, John Levine wrote: >>> Is CBOR intended to simply be an alternative encoding for JSON? >> My recollection is that during the discussion of CBOR, the authors >> said rather firmly that although CBOR has obvious resemblances to >> JSON, it's not JSON. If you look at both of them, you can see that >> CBOR already has all sorts of stuff beyond is in JSON, such as a >> distinction between integer and floating point values, and semantic >> tags that let you say things like this string represents a date. >> >> Perhaps Paul and Carsten could clarify here. >> >>> ISTM it would be good if a single schema representation was applicable >>> to both JSON and CBOR. >> I see why one would want that, but given the existing semantic >> differences between JSON and CBOR, I doubt it's feasible. > > John is correct. > > Additionally, it can be said that CBOR is a "superset" of JSON, in that > the semantic content of JSON texts [RFC7159] are representable in native > CBOR. > > "Possible" for a JSON+CBOR schema yes; "feasible" no. Additionally, JSON > schema technology already exists.already. I know. That is why I asked. It seems like it might be evolved to serve both, even if one is richer than the other. Thanks, Paul From nobody Wed Oct 19 05:54:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164D1129622 for ; Wed, 19 Oct 2016 05:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bURK9Z4iPG63 for ; Wed, 19 Oct 2016 05:54:21 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 E804512960C for ; Wed, 19 Oct 2016 05:54:20 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 4so111144929itv.0 for ; Wed, 19 Oct 2016 05:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KgpIKQCUMR7SqZ6jnvs+g4l7DpbUQlu6SC/hIvCLvPA=; b=NWW8YJEPQ7FxgLjomeZGfsNFgm+4BcV/unXZLNuhD1Iqq54idFkhaWGxNUvxc8bSqr U8Jc9J1px0MU0OR1RHop1SspXbhMMgqsJtRPgKDcs+Mx7l1BPwzykD5IHZ8SDYmgzj52 9ff1WIael0ZzQ2Ynbi0AxLOyvSwzb0dejXStraqpiNva2ODTZq4jcBeHr/bfDF4r7aA7 qncCRiaXKZhoOZi057Kmwq5bcMWlc8lQvnZ872qya4tMRocwNwPmk1HF7m78ohjXcDR7 /qlXHPhUMWFKfyEoIONZIuPjUzInyn48D73Uv5U7QL2Jhw8CDuyIgg5R7HJXThVgIVwR 4sAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KgpIKQCUMR7SqZ6jnvs+g4l7DpbUQlu6SC/hIvCLvPA=; b=Z5ZMaVMaBhsGSJ8U80WuYPfwCqDgfSjIQDSZdrxIWKCIpsdPhdar+VvFaabBAy71FB E2iCF6JyLO52UZKSjiVPVhx9PPmZkClHsArJ6txLqNkKUpX3BRu4xTGrubiW3TVfGoze 0on79cuLq9kbGoaxSaBMD+wj8BhvbObPFkav3RnV0dhMrUMcdLUd90f/Y69GRzIItZpe jQ22yj+4G+zgb2oz9iw9OBXz4VXxnRemvkIyNlSE8K+v9M247m3JZNaIiMlQ+SKJNToL piRWPWTu43qSaVwWv9FWxxzqzst2FwcDwU2JecTkxEsjGOJaJPX6OyHgS+e7HPGPUwCZ S+Ww== X-Gm-Message-State: AA6/9RkJRadbhSDPX4yWGGMFnQ+LiS7yCDSjhO6gAHPuKxQ/RoJaVlZmLKkiJURqSRFzS+BL3xXFaipRH6jhCw== X-Received: by 10.36.163.69 with SMTP id p66mr2816105ite.6.1476881660183; Wed, 19 Oct 2016 05:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.147.6 with HTTP; Wed, 19 Oct 2016 05:53:59 -0700 (PDT) In-Reply-To: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> References: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> From: Ira McDonald Date: Wed, 19 Oct 2016 08:53:59 -0400 Message-ID: To: Alexey Melnikov , Ira McDonald , Henk Birkholz Content-Type: multipart/alternative; boundary=94eb2c049858bb2f06053f374e4f Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 12:54:24 -0000 --94eb2c049858bb2f06053f374e4f Content-Type: text/plain; charset=UTF-8 Hi, +1 to the proposed charter, speaking as someone who has been using CBOR (and the evolving CDDL) in three non-IETF standards bodies for two years (TCG, IEEE, and SAE). In these other standards efforts the strong typing on the wire of CBOR and extreme compactness are the primary attractions. The evolving CDDL is a powerful schema language that shows promise for excellent runtime validation of complex messages. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Oct 18, 2016 at 10:58 AM, Alexey Melnikov wrote: > Hi, > I received a request to form a new WG that will work on revising CBOR (RFC > 7049), finishing CDDL and working on a couple of CBOR extensions. > > Please comment on the proposed charter and proposed work. > > --------- > > Concise Binary Object Representation (CBOR, RFC 7049) extends the > JavaScript Object Notation (JSON, RFC 7159) data model to include binary > data and an extensibility model, using a binary representation format that > is easy to parse correctly. It has been picked up by a number of IETF > efforts (e.g., COSE, GRASP) as a message format. > > The CBOR working group will update RFC 7049 to fix verified errata. > Security issues and clarifications may be addressed, but changes to the > document will ensure backward compatibility for popular deployed codebases. > The resulting document will be targeted at becoming an Internet Standard. > > Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of > valid messages in a text representation, it would be useful if protocol > specifications could use a description format for the data in CBOR-encoded > messages. The CBOR data definition language (CDDL) is a proposal for such > a description technique that has already been used successfully in COSE, > GRASP, and efforts outside the IETF. The CBOR WG will complete the > development of this specification by creating an RFC that can be used as a > normative reference in a protocol specification. > > In parallel to the work on CDDL, the WG will examine the > Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid > that > use CBOR's extensibility mechanisms to provide additional data types as > used in certain applications. Where these proposals are deemed useful and > do not require significant new > development, the CBOR WG might complete these specifications as well. > --------- > > Best Regards, > Alexey, as an ART AD. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --94eb2c049858bb2f06053f374e4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

+1 to = the proposed charter, speaking as someone who has been
using CBOR = (and the evolving CDDL) in three non-IETF standards
bodies for two= years (TCG, IEEE, and SAE).

In these other standards efforts = the strong typing on the wire of
CBOR and extreme compactness are= the primary attractions.
The evolving CDDL is a powerful sch= ema language that shows
promise for excellent runtime validat= ion of complex messages.

Cheers,
- Ira
=


On Tue, Oct 18, 2016 at 10:58 AM, Alexey Mel= nikov <alexey.melnikov@isode.com> wrote:
Hi,
I received a request to form a new WG that will work on revising CBOR (RFC = 7049), finishing CDDL and working on a couple of CBOR extensions.

Please comment on the proposed charter and proposed work.

---------

Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScrip= t Object Notation (JSON, RFC 7159) data model to include binary data and an= extensibility model, using a binary representation format that is easy to = parse correctly. It has been picked up by a number of IETF efforts (e.g., C= OSE, GRASP) as a message format.

The CBOR working group will update RFC 7049 to fix verified errata. Securit= y issues and clarifications may be addressed, but changes to the document w= ill ensure backward compatibility for popular deployed codebases. The resul= ting document will be targeted at becoming an Internet Standard.

Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of = valid messages in a text representation, it would be useful if protocol spe= cifications could use a description format for the data in CBOR-encoded mes= sages.=C2=A0 The CBOR data definition language (CDDL) is a proposal for suc= h a description technique that has already been used successfully in COSE, = GRASP, and efforts outside the IETF.=C2=A0 The CBOR WG will complete the de= velopment of this specification by creating an RFC that can be used as a no= rmative reference in a protocol specification.

In parallel to the work on CDDL, the WG will examine the
Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid tha= t
use CBOR's extensibility mechanisms to provide additional data types as= used in certain applications.=C2=A0 Where these proposals are deemed usefu= l and do not require significant new
development, the CBOR WG might complete these specifications as well.
---------

Best Regards,
Alexey, as an ART AD.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--94eb2c049858bb2f06053f374e4f-- From nobody Thu Oct 20 06:01:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF87127ABE for ; Thu, 20 Oct 2016 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 xEVRtcjVIU8e for ; Thu, 20 Oct 2016 06:01:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0621E1294EE for ; Thu, 20 Oct 2016 06:01:46 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-ac-5808c037745e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 03.F0.02458.730C8085; Thu, 20 Oct 2016 15:01:45 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.139]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Thu, 20 Oct 2016 15:01:43 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: Ira McDonald Thread-Topic: [dispatch] Proposed CBOR / CDDL WG Thread-Index: AQHSKVD/ZjdNS5V/VEGCttyou2P4RKCvm46AgAGUfIA= Date: Thu, 20 Oct 2016 13:01:42 +0000 Message-ID: <9ABF40D9-2654-4BFA-B3D5-66A0B98B257F@ericsson.com> References: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/signed; boundary="Apple-Mail=_6F2CE144-42E5-402F-8E2F-671144264C41"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyM2J7uK7lAY4Ig7fXWCxmrC6yeP1qKbvF 0kkLWC0a/v1ldWDx2DnrLrvHkiU/mTxONRt6dDy4wRjAEsVlk5Kak1mWWqRvl8CVcer/JLaC 512MFb/fHmRvYLxU08XIySEhYCLx9MURli5GLg4hgfWMEj9+z2SDcJYwSlz50ssKUsUm4Czx 6VkjexcjB4eIgJbEkueKIDXMAt2MEnfWHmcCqREW0Jf4caOXBcQWETCQePF8ATuEbSWxcslP NhCbRUBVYtmvbWA2r4C9xLE5M9ghljUzSmy5dYENZAGnQKDErzZNkBpGATGJ76fWgM1nFhCX uPVkPhPE1SISDy+eZoOwRSVePv7HCmErSazYfokR4rgpjBJNl2ayQywTlDg58wnLBEaRWUhm zUJWNwtJHURRksSB74eZIGxtiWULXzND2JoS+7uXs2CKa0h0fpvICmGbSrw++pERwraWmPHr IBuErSgxpfsh+wJG7lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgTF+cMtvqx2MB587HmIU 4GBU4uF98IY9Qog1say4MvcQowrQnEcbVl9glGLJy89LVRLhfbyHI0KINyWxsiq1KD++qDQn tfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGxlid+8y/Vnx9curBJIHOKuED+5I2 HP9oondAZPaLHx1N7rG+bIvvXeLcxG1q0/SQQdk/1P31vNBvSfy6+xxDnMwNl1smSGZ89Zi9 85fyhEvfZodkRkzI6kmV+a56c2n0zUtaElUH10x1TNM6nRt6/oONwdVKiQg9o1ZmXu6Dah7C zx0Ci04pKLEUZyQaajEXFScCAGhXw2X5AgAA Archived-At: Cc: Alexey Melnikov , "dispatch@ietf.org" , Henk Birkholz Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 13:01:51 -0000 --Apple-Mail=_6F2CE144-42E5-402F-8E2F-671144264C41 Content-Type: multipart/alternative; boundary="Apple-Mail=_68BE7018-26EF-4672-A85F-71EC5D938D37" --Apple-Mail=_68BE7018-26EF-4672-A85F-71EC5D938D37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, +1 to this as well.=20 One comment, isn=E2=80=99t RFC7049 normative already? Is CDDL=E2=80=99s = normative doc the one missing? Ciao, - - Jaime Jim=C3=A9nez > On 19 Oct 2016, at 15:53, Ira McDonald = wrote: >=20 > Hi, >=20 > +1 to the proposed charter, speaking as someone who has been > using CBOR (and the evolving CDDL) in three non-IETF standards > bodies for two years (TCG, IEEE, and SAE). >=20 > In these other standards efforts the strong typing on the wire of=20 > CBOR and extreme compactness are the primary attractions. > The evolving CDDL is a powerful schema language that shows > promise for excellent runtime validation of complex messages. >=20 > Cheers, > - Ira >=20 >=20 > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic = > http://sites.google.com/site/highnorthinc = > mailto: blueroofmusic@gmail.com > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 >=20 >=20 > On Tue, Oct 18, 2016 at 10:58 AM, Alexey Melnikov = > wrote: > Hi, > I received a request to form a new WG that will work on revising CBOR = (RFC 7049), finishing CDDL and working on a couple of CBOR extensions. >=20 > Please comment on the proposed charter and proposed work. >=20 > --------- >=20 > Concise Binary Object Representation (CBOR, RFC 7049) extends the = JavaScript Object Notation (JSON, RFC 7159) data model to include binary = data and an extensibility model, using a binary representation format = that is easy to parse correctly. It has been picked up by a number of = IETF efforts (e.g., COSE, GRASP) as a message format. >=20 > The CBOR working group will update RFC 7049 to fix verified errata. = Security issues and clarifications may be addressed, but changes to the = document will ensure backward compatibility for popular deployed = codebases. The resulting document will be targeted at becoming an = Internet Standard. >=20 > Similar to the way ABNF (RFC 5234/7405) can be used to describe the = set of valid messages in a text representation, it would be useful if = protocol specifications could use a description format for the data in = CBOR-encoded messages. The CBOR data definition language (CDDL) is a = proposal for such a description technique that has already been used = successfully in COSE, GRASP, and efforts outside the IETF. The CBOR WG = will complete the development of this specification by creating an RFC = that can be used as a normative reference in a protocol specification. >=20 > In parallel to the work on CDDL, the WG will examine the > Internet-Drafts draft-jroatch-cbor-tags and = draft-bormann-cbor-tags-oid that > use CBOR's extensibility mechanisms to provide additional data types = as used in certain applications. Where these proposals are deemed = useful and do not require significant new > development, the CBOR WG might complete these specifications as well. > --------- >=20 > Best Regards, > Alexey, as an ART AD. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_68BE7018-26EF-4672-A85F-71EC5D938D37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

+1 to = this as well. 

One comment, isn=E2=80=99t  RFC7049 normative already? = Is CDDL=E2=80=99s normative doc the one missing?

Ciao,
- - Jaime Jim=C3=A9nez

On 19 Oct 2016, at 15:53, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi,

+1 to = the proposed charter, speaking as someone who has been
using CBOR (and the evolving CDDL) in three non-IETF = standards
bodies for two years (TCG, IEEE, and = SAE).

In these other standards = efforts the strong typing on the wire of
CBOR and = extreme compactness are the primary attractions.
The evolving CDDL is a powerful schema language that shows
promise for excellent runtime = validation of complex messages.

Cheers,
- Ira


Ira McDonald (Musician / Software = Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  = 734-944-0094
May-Dec: PO Box 221  Grand Marais, MI = 49839  906-494-2434


On Tue, Oct 18, 2016 at 10:58 = AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi,
I received a request to form a new WG that will work on revising CBOR = (RFC 7049), finishing CDDL and working on a couple of CBOR = extensions.

Please comment on the proposed charter and proposed work.

---------

Concise Binary Object Representation (CBOR, RFC 7049) extends the = JavaScript Object Notation (JSON, RFC 7159) data model to include binary = data and an extensibility model, using a binary representation format = that is easy to parse correctly. It has been picked up by a number of = IETF efforts (e.g., COSE, GRASP) as a message format.

The CBOR working group will update RFC 7049 to fix verified errata. = Security issues and clarifications may be addressed, but changes to the = document will ensure backward compatibility for popular deployed = codebases. The resulting document will be targeted at becoming an = Internet Standard.

Similar to the way ABNF (RFC 5234/7405) can be used to describe the set = of valid messages in a text representation, it would be useful if = protocol specifications could use a description format for the data in = CBOR-encoded messages.  The CBOR data definition language (CDDL) is = a proposal for such a description technique that has already been used = successfully in COSE, GRASP, and efforts outside the IETF.  The = CBOR WG will complete the development of this specification by creating = an RFC that can be used as a normative reference in a protocol = specification.

In parallel to the work on CDDL, the WG will examine the
Internet-Drafts draft-jroatch-cbor-tags and draft-bormann-cbor-tags-oid = that
use CBOR's extensibility mechanisms to provide additional data types as = used in certain applications.  Where these proposals are deemed = useful and do not require significant new
development, the CBOR WG might complete these specifications as well.
---------

Best Regards,
Alexey, as an ART AD.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_68BE7018-26EF-4672-A85F-71EC5D938D37-- --Apple-Mail=_6F2CE144-42E5-402F-8E2F-671144264C41 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMjAxMzAxNDJaMCMGCSqGSIb3DQEJBDEWBBTP 3lkHdyFDY8Z5Cz39l6OdAjY8SzBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQCaC+4ZnmgUDNkzI6VQmlLUveqwKbTpCZnb2gEKL95bD5yn0QxDtxlCT939N1zionbo/h+Ejvoc /FVZOG38saT87HZgbem+D3y/7wXJ9RddIJd9OIkuYvvnlDhmNsG47MKzFiiAUpNwcbiMhbMPGYpt qj0SOI4X+6gEo2EAj44H4D5rPGtJPUlBuLAnVmgIVjvaaVmC+WNV/QczaE1VaYyacJFdOtdmsqo9 bQEgRiP+bxqPFGFpFNqz8LQ4pBFYDTibKQrh18FaKZAI/+Losv9cbemFq74boP4LCT2HkcfHGy6O qdUYqEawSpENTxKQ3L2yKyCj73cIMj5e0zQYKkyMAAAAAAAA --Apple-Mail=_6F2CE144-42E5-402F-8E2F-671144264C41-- From nobody Fri Oct 21 15:04:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FCD12968C for ; Fri, 21 Oct 2016 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] 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 s8-Ty2EAaIa6 for ; Fri, 21 Oct 2016 15:04:24 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E1C2129683 for ; Fri, 21 Oct 2016 15:04:23 -0700 (PDT) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d43 with ME id yN4K1t00M17Lgi403N4LsF; Sat, 22 Oct 2016 00:04:21 +0200 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Sat, 22 Oct 2016 00:04:21 +0200 X-ME-IP: 92.170.5.52 To: dispatch@ietf.org References: <20160913201142.53911.qmail@ary.lan> <6e3f97bd-31a8-4e09-3790-f90c042cf073@trigofacile.com> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <4b62d5ef-4ee6-d4f8-6c6e-9910448ce52c@trigofacile.com> Date: Sat, 22 Oct 2016 00:04:19 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6e3f97bd-31a8-4e09-3790-f90c042cf073@trigofacile.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: John Levine Subject: Re: [dispatch] Review of two drafts refreshing the use of TLS with NNTP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 22:04:26 -0000 Hi John, >>> https://tools.ietf.org/html/draft-murchison-nntp-compress-05 >> >> It's not clear in all of section 3 whether the advice is based on >> observations of how traffic actually compresses, or guesses about what >> will happen. Do you know which it is? > > I ran some tests last year about compression ratios, and Bo Lindbergh > about the use of different flush options: > https://groups.google.com/forum/#!topic/news.software.nntp/ZXrwlcAUMMM > (thread beginning with Message-ID ) > >> If it's observation, the whole section can stay. If it's guesses, >> the whole section should go. > > We can then keep it in Section 3 instead of an Appendix. FYI, your remark is now taken into account: https://github.com/ksmurchison/drafts/commit/98889548a217f628c8bf19ae558032ef63b3df2e Thanks again for it! -- Julien ÉLIE « – Ils transportent une arme secrète dans un tonneau ! – La cervoise tiède !!! – Non, ça c'est une arme connue. » (Astérix) From nobody Fri Oct 21 16:25:34 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A1912985F; Fri, 21 Oct 2016 16:21:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207415.28214.4668241239190207472.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:14 -0700 Archived-At: Cc: ben@nostrum.com, dispatch@ietf.org Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 97 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:18 -0000 Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (1:30:00) Monday, Morning Session I 0930-1200 Room Name: Grand Ballroom 2 size: 200 --------------------------------------------- Special Note: 09:30-11:00 Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 175 Conflicts to Avoid: First Priority: appsawg core clue bfcpbis avtext avtcore apparea dbound ecrit insipid mmusic netvc p2psip payload rmcat rtcweb sipcore siprec stir stox straw webpush xrblock Second Priority: tram tsvwg tsvarea opsarea lmap Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Sat Oct 22 02:12:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438A21296FD for ; Sat, 22 Oct 2016 02:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 aDWG5OUm_mP5 for ; Sat, 22 Oct 2016 02:12:15 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002-out.apm-internet.net [85.119.248.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118221296F7 for ; Sat, 22 Oct 2016 02:12:14 -0700 (PDT) Received: (qmail 53544 invoked from network); 22 Oct 2016 09:12:12 -0000 X-AV-Scan: skipped X-APM-Authkey: 83769/0 604 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 22 Oct 2016 09:12:12 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 83B3618A02E1 for ; Sat, 22 Oct 2016 10:12:12 +0100 (BST) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 73F2C18A03BD for ; Sat, 22 Oct 2016 10:12:12 +0100 (BST) Received: from [192.67.4.155] (unknown [192.67.4.155]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 60B2918A02E1 for ; Sat, 22 Oct 2016 10:12:12 +0100 (BST) From: westhawk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <43C108AF-552A-46C6-8614-21C41940BD3B@westhawk.co.uk> Date: Sat, 22 Oct 2016 10:12:11 +0100 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] ICMP Source Quench BIS anyone ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 09:12:17 -0000 This morning makes me wonder if https://tools.ietf.org/html/rfc6633 was = a catastrophic mistake. From nobody Sun Oct 23 19:26:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4737012945C for ; Sun, 23 Oct 2016 19:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 4CYaqVU4-oRP for ; Sun, 23 Oct 2016 19:25:56 -0700 (PDT) Received: from smtp88.ord1c.emailsrvr.com (smtp88.ord1c.emailsrvr.com [108.166.43.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFFA1293F0 for ; Sun, 23 Oct 2016 19:25:56 -0700 (PDT) Received: from smtp4.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 57152A018B; Sun, 23 Oct 2016 22:25:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5A430A0182; Sun, 23 Oct 2016 22:25:48 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.41.128] ([UNAVAILABLE]. [128.107.241.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.7); Sun, 23 Oct 2016 22:25:51 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A8E3E9F5-F684-4ECE-A746-3FDC7F552011" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> Date: Sun, 23 Oct 2016 20:25:42 -0600 Message-Id: <0CED4006-9029-47D7-8CB1-E0A62B723226@iii.ca> References: <2a40ff7a-090f-848f-b35a-aa0944d26294@isode.com> To: DISPATCH X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Alexey Melnikov Subject: Re: [dispatch] Proposed CBOR / CDDL WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 02:26:09 -0000 --Apple-Mail=_A8E3E9F5-F684-4ECE-A746-3FDC7F552011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 18, 2016, at 8:58 AM, Alexey Melnikov = wrote: >=20 >=20 > In parallel to the work on CDDL, the WG will examine the > Internet-Drafts draft-jroatch-cbor-tags and = draft-bormann-cbor-tags-oid that > use CBOR's extensibility mechanisms to provide additional data types = as used in certain applications. Where these proposals are deemed = useful and do not require significant new > development, the CBOR WG might complete these specifications as well. Would it be possible to write this up in a way that said what the WG = would accomplish vs which drafts it would adopt ? --Apple-Mail=_A8E3E9F5-F684-4ECE-A746-3FDC7F552011 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 18, 2016, at 8:58 AM, = Alexey Melnikov <alexey.melnikov@isode.com> wrote:


In parallel to the = work on CDDL, the WG will examine the
Internet-Drafts draft-jroatch-cbor-tags = and draft-bormann-cbor-tags-oid that
use CBOR's extensibility mechanisms to = provide additional data types as used in certain applications. =  Where these proposals are deemed useful and do not require = significant new
development, the CBOR WG might complete these = specifications as well.

Would it be possible to write this up in a way that said = what the WG would accomplish vs which drafts it would adopt ?


= --Apple-Mail=_A8E3E9F5-F684-4ECE-A746-3FDC7F552011-- From nobody Thu Oct 27 08:07:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA7129884 for ; Thu, 27 Oct 2016 08:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=jMH2ZAhp; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=tmObmUtt 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 8O979ARAzL8B for ; Thu, 27 Oct 2016 08:07:14 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A456412951E for ; Thu, 27 Oct 2016 08:07:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 15AF52076A for ; Thu, 27 Oct 2016 11:07:08 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 27 Oct 2016 11:07:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=dZGNmYUSxtdZCKbxgDAoNtCpGsw=; b=jMH2ZA hpR3td8wZzApZnfihWh6esU3EtMYj/yac0W68FTSIUiIIxpKaeenm+iDI7II5D2e 7/lRMJ0nW6ETvEJRWNURZxsPJXerGF/cAJ6YwUkvK8VKa5mXqWHHQwBHc93AOppb 14qunpsnF/BIxto0Ika7CEo8RuAfbgKKhlGsM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=dZGNmYUSxtdZCK bxgDAoNtCpGsw=; b=tmObmUttjxwHxkd7aWo9pEDfeQsU+c+sTo+EhjJErGT1w0 RixuLJc5TRL0k8JHc4NDfpKGIsz8+l4bma6lkOiT32jMEnEgxCtikW5XEwp3Tqm6 RKxzpxvDR/dsMukLKM6qt101AlpUYKbgYGEXzLqJXKvR3wWFBXuKMnkhIJCmQ= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D2A1296EA2; Thu, 27 Oct 2016 11:07:07 -0400 (EDT) Message-Id: <1477580827.1391268.769211521.42081A52@webmail.messagingengine.com> X-Sasl-Enc: cHlsx3/1Gz1M7M2zWqlBWReLHHTbGdN3Nn0aafVrREgt 1477580827 From: Alexey Melnikov To: DISPATCH MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-996895c6 Date: Thu, 27 Oct 2016 16:07:07 +0100 Archived-At: Subject: [dispatch] Possible new work: WebDAV extensions X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 15:07:19 -0000 Hi, I've been asked about possibly forming a new WG working on WebDAV extensions, for example: https://datatracker.ietf.org/doc/draft-pot-webdav-notifications/ https://datatracker.ietf.org/doc/draft-pot-webdav-resource-sharing/ https://datatracker.ietf.org/doc/draft-pot-caldav-sharing/ https://datatracker.ietf.org/doc/draft-pot-carddav-sharing/ I would like to get a sense of whether anybody is going to be interested in a standalone WG for this. If not, I am likely to ask CALEXT WG (which depend on many of these) to progress these documents. Thank you, Alexey From nobody Mon Oct 31 10:58:34 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B92129997; Mon, 31 Oct 2016 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] 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 aFzVvOBMyrH0; Mon, 31 Oct 2016 10:58:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2BA129992; Mon, 31 Oct 2016 10:58:27 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 412AB22E256; Mon, 31 Oct 2016 13:58:24 -0400 (EDT) References: <147789410169.20603.10762538514881009790.idtracker@ietfa.amsl.com> To: dispatch@ietf.org, ietf-smtp From: Sean Leonard X-Forwarded-Message-Id: <147789410169.20603.10762538514881009790.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 31 Oct 2016 10:58:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147789410169.20603.10762538514881009790.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Regular Expressions for Internet Mail Fwd: New Version Notification for draft-seantek-mail-regexen-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 17:58:29 -0000 draft-seantek-mail-regexen-01 Hello: Regular Expressions for Internet Mail draft-01 has been updated. There is a brief change log in Appendix B, which is reprinted below. I/we look forward to discussing and hopefully getting this dispatched. Regards, Sean (and co-authors) Appendix B. Change Log The document status is now marked as Informational instead of Best Current Practice (although it seems that it could go either way). The authors decided to focus on "modern" ASCII-only email identifiers first and to get those right before tackling Unicode email identifiers and "obsolete" ABNF productions. This draft-01 preserves the main text of draft-00 rather than remove potentially useful text. Deliverable and modern email addresses, and modern Message-IDs, have been addressed. The Unicode work remains unfinished for now; "obsolete" ABNF productions (which are still useful for archival applications) will also be addressed in future drafts. The authors decided to write one set of regular expressions in one dialect (namely, PCRE/PCRE2) before tackling others (e.g., JavaScript). Different dialects will be addressed in future drafts. -------- Forwarded Message -------- Subject: New Version Notification for draft-seantek-mail-regexen-01.txt Date: Sun, 30 Oct 2016 23:08:21 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-seantek-mail-regexen-01.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-mail-regexen Revision: 01 Title: Regular Expressions for Internet Mail Document date: 2016-10-30 Group: Individual Submission Pages: 28 URL: https://www.ietf.org/internet-drafts/draft-seantek-mail-regexen-01.txt Status: https://datatracker.ietf.org/doc/draft-seantek-mail-regexen/ Htmlized: https://tools.ietf.org/html/draft-seantek-mail-regexen-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-seantek-mail-regexen-01 Abstract: Internet Mail identifiers are used ubiquitously throughout computing systems as building blocks of online identity. Unfortunately, incomplete understandings of the syntaxes of these identifiers has led to interoperability problems and poor user experiences. Many users use specific characters in their addresses that are not properly accepted on various systems. This document prescribes normative regular expression (regex) patterns for all Internet- connected systems to use when validating or parsing Internet Mail identifiers, with special attention to regular expressions that work with popular languages and platforms.