Re: [stir] current draft charter

Hadriel Kaplan <hadriel.kaplan@oracle.com> Mon, 17 June 2013 06:18 UTC

Return-Path: <hadriel.kaplan@oracle.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98421F9A8B for <stir@ietfa.amsl.com>; Sun, 16 Jun 2013 23:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0ga8G6yDREl for <stir@ietfa.amsl.com>; Sun, 16 Jun 2013 23:18:32 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16B21F9A87 for <stir@ietf.org>; Sun, 16 Jun 2013 23:18:32 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5H6IOJc013589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jun 2013 06:18:25 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5H6IQQ2004530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 06:18:27 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5H6IQKU012664; Mon, 17 Jun 2013 06:18:26 GMT
Received: from dhcp-amer-vpn-adc-anyconnect-10-154-171-126.vpn.oracle.com (/10.154.171.126) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 16 Jun 2013 23:18:26 -0700
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <CDE38BC3.20F76%jon.peterson@neustar.biz>
Date: Mon, 17 Jun 2013 02:18:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com>
References: <CDE38BC3.20F76%jon.peterson@neustar.biz>
To: "Peterson, Jon" <jon.peterson@neustar.biz>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "stir@ietf.org" <stir@ietf.org>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>
Subject: Re: [stir] current draft charter
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 06:18:39 -0000

On Jun 16, 2013, at 7:27 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote:

> The exact amount of tolerable delay is a very interesting dimension of
> this problem space. I suspect we have a considerable amount of time, given
> all the human expectations about both post-dial delay and the wait for
> someone to pick up after altering. I think it's enough time to perform
> some non-trivial operations.

I've been thinking about that and I'm not sure we actually have much time.  I've been looking at what the CNAM guys are doing, and at least one them (used in a large mobile provider) goes so far as to sometimes skip it on the INVITE and send their CNAM info in an UPDATE or INFO afterwards due to the delay.  I.e., they have us queue the INVITE while they retrieve the CNAM info for the given caller-id, but if they take too long then we send the INVITE and send their results separately afterwards in another message.  Another operator that uses private ENUM for CNAM querying also sets very low timeouts on the query, and just don't provide a calling name if it times out (ie., the INVITE gets sent on without it, and nothing updates it later).

Also, Brian at one point mentioned transit providers possibly doing the verification check as well, and that might be difficult if it takes non-trivial time I think, because one of the SLA measurements they get ranked on is how fast they route their calls onward.  (Besides which they're never involved this type of stuff so I'd doubt they'd start now anyway.)

Anecdotally, I find that intra-nation calls get to ringing stage much faster than international calls, so people are probably ok with international caller-id verification taking longer.

-hadriel