Re: [stir] current draft charter

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 17 June 2013 12:14 UTC

Return-Path: <hgs@cs.columbia.edu>
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 058E221F9BA2 for <stir@ietfa.amsl.com>; Mon, 17 Jun 2013 05:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.463
X-Spam-Level:
X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lF0zCNGywJLx for <stir@ietfa.amsl.com>; Mon, 17 Jun 2013 05:14:49 -0700 (PDT)
Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 190D421F9B77 for <stir@ietf.org>; Mon, 17 Jun 2013 05:14:27 -0700 (PDT)
Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r5HCEKw8003096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Jun 2013 08:14:21 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com>
Date: Mon, 17 Jun 2013 08:14:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5C27090-FF39-4FBC-BC7E-F2ACFA5A4E6F@cs.columbia.edu>
References: <CDE38BC3.20F76%jon.peterson@neustar.biz> <6BAABF96-8892-4C50-BB30-5F1FC05BDFD8@oracle.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
X-Mailer: Apple Mail (2.1283)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5
Cc: "stir@ietf.org" <stir@ietf.org>, "dcrocker@bbiw.net" <dcrocker@bbiw.net>, "Peterson, Jon" <jon.peterson@neustar.biz>
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 12:15:01 -0000

I wouldn't be surprised if the large carriers cache all certs locally. For +1, I'd suggest that's less than a TB, i.e., a single disk, even if every number has their own cert, rather than number ranges. They would then subscribe to a notification service for any porting-related changes, given that such changes affect a very small fraction of the numbers (quarterly churn of mobile carriers is about 1-2%). This can all be done within the carrier network, i.e., without affecting the external public data interface.

On Jun 17, 2013, at 2:18 AM, Hadriel Kaplan wrote:

> 
> 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
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>