Re: [stir] current draft charter - ENUM and databases

"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com> Wed, 19 June 2013 14:37 UTC

Return-Path: <yiu_lee@cable.comcast.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 9228521F9CAF for <stir@ietfa.amsl.com>; Wed, 19 Jun 2013 07:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.231
X-Spam-Level:
X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 0lEId4HRUjGL for <stir@ietfa.amsl.com>; Wed, 19 Jun 2013 07:37:32 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1821F9C97 for <stir@ietf.org>; Wed, 19 Jun 2013 07:37:29 -0700 (PDT)
Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.78127081; Wed, 19 Jun 2013 08:36:51 -0600
Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.207]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 19 Jun 2013 10:37:24 -0400
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] current draft charter - ENUM and databases
Thread-Index: AQHObPqD88zMB0Ss20iZGGbgRFBatg==
Date: Wed, 19 Jun 2013 14:37:23 +0000
Message-ID: <E3FAB1F4F41F3A45B287E8D9C53522FD472CEF2B@PACDCEXMB05.cable.comcast.com>
In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3A03DEDDE@ex2k10mb2.corp.yaanatech.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [68.87.16.248]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3454483043_281015"
MIME-Version: 1.0
Subject: Re: [stir] current draft charter - ENUM and databases
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: Wed, 19 Jun 2013 14:37:37 -0000

No disagreement. I am curious what Hadriel tried to illustrate in the
example so that I can understand his idea better.

On 6/19/13 9:37 AM, "Michael Hammer" <michael.hammer@yaanatech.com> wrote:

>Is that out of scope?
>
>Should we focus on E.164 first, email-style names second, and the
>interworking of the two third?
>
>That wouldn't preclude reuse of solution to one for the other, or thinking
>about that in advance.
>But, we are talking about two different authority delegation trees here
>and 
>I am not sure if you want one constrained by solutions for the other.
>
>If we do, then at least make it clear that is a decision being made.
>
>Mike
>
>
>-----Original Message-----
>From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of
>Lee,
>Yiu
>Sent: Wednesday, June 19, 2013 9:15 AM
>To: stir@ietf.org
>Subject: Re: [stir] current draft charter - ENUM and databases
>
>I am on board using dns for lookup. One question in your example: When you
>receive alice@foo.com, how do you derive it to "_cid.foo.com"? Do you
>suggest _cid is the tn or some other identifier?
>
>
>On 6/18/13 1:36 PM, "Hadriel Kaplan" <hadriel.kaplan@oracle.com> wrote:
>
>>I think that's still possible even for email-style names.  For example,
>>when receiving a request from'alice@foo.com' we could do a DNS lookup
>>for '_cid.foo.com' or some such pre-defined naming scheme, to get the
>>caller-id cert for 'foo.com'; or the RR for that DNS key could redirect
>>us to somewhere else if need be.  Or we could do an HTTP automatically
>>for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where
>>the last part is a hash of the username.