Re: [stir] current draft charter

Hadriel Kaplan <hadriel.kaplan@oracle.com> Thu, 13 June 2013 16:14 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 80B8021F9A1C for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 09:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.567
X-Spam-Level:
X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 nxv9k74+6-uT for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 09:14:18 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D921F994F for <stir@ietf.org>; Thu, 13 Jun 2013 09:14:13 -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 r5DGDrmY003214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 16:13:54 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5DGDrQ4001388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 16:13:54 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5DGDrVo016576; Thu, 13 Jun 2013 16:13:53 GMT
Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Jun 2013 09:13:53 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <BEBF7B2F-997E-4428-B6CE-2F77B5F910E4@brianrosen.net>
Date: Thu, 13 Jun 2013 12:13:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <59D0F1E7-7682-4787-B93F-D17C64D27B23@oracle.com>
References: <CDDF354D.DD9A%york@isoc.org> <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <BEBF7B2F-997E-4428-B6CE-2F77B5F910E4@brianrosen.net>
To: Brian Rosen <br@brianrosen.net>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Wendt, Chris" <Chris_Wendt@cable.comcast.com>, Dan York <york@isoc.org>, "Peterson, Jon" <jon.peterson@neustar.biz>, "stir@ietf.org" <stir@ietf.org>, Dave Crocker <dcrocker@bbiw.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Henning Schulzrinne <hgs@cs.columbia.edu>
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: Thu, 13 Jun 2013 16:14:24 -0000

On Jun 13, 2013, at 10:08 AM, Brian Rosen <br@brianrosen.net> wrote:

> So, my response is the same as I have given before: the privacy and operational issues of putting per TN information in the public DNS are overwhelming.  We have tried it, and it has failed.

The privacy issues can be avoided.

The operational issues, however, are quite significant.  But I don't see how they're not significant no matter what databases we put them in.  No matter whether it's a private database or public one: there will be new operational procedures, forms to fill out, help desk people to handle problems with it, configuration and deployment of stuff, NOC personnel to train, testing to do, monitoring systems to monitor it, etc., etc.

In short: it's a very big deal.

Luckily history has shown that some third-party service companies will make themselves available to do most of the work for carriers that don't want to do it themselves, for a fee.  It might be the number portability vendors, or CNAM vendors, or something new.  Either way, they can handle most of the heavy lifting for carriers who don't want to.  If we choose a DNS model, then those third-party vendors would then interface to the DNS admin; or maybe they start with a private federation of servers just among the third-party companies.

The reason Public ENUM failed wasn't because it was an operational nightmare - if Public ENUM had some actual useful benefit to the stakeholders, then all other issues would have gone away or been dealt with.  I.e., if the carriers *want* something, then they figure out how to get it done, how to lobby their Regulators, and how to get the ITU to go along.  If they don't want it, then every possible issue that can be raised becomes "impossible to fix".  And I'm not saying that's wrong either. (and everyone does the same thing in the IETF, regularly)


> Unlike Hadriel, you really do want to disclose domain with TN.  That has been a non-starter for many carriers.

In my defense, it's not that *I* don't want to disclose the domain of the TN - I'd be perfectly happy with it - it's that I'm pretty sure a lot of providers AND Enterprises would not, if it means you can discover all the TNs belonging to the domain.  And you don't need to go very far to find evidence of that: how many companies want to publicly disclose all their users' email addresses?  Of my current and half-dozen previous employers, none would want them exposed.

-hadriel