From nobody Wed Oct 15 11:51:19 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56711A90D2 for ; Wed, 15 Oct 2014 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 R6pwOdgEDzE4 for ; Wed, 15 Oct 2014 11:50:57 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 49DB11A90C3 for ; Wed, 15 Oct 2014 11:50:37 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "modern@ietf.org" Thread-Topic: Almost Halloween - time to wake the numbering zombies Thread-Index: Ac/oqN9MlbpBalWpRUaUeHInRzS4qw== Date: Wed, 15 Oct 2014 18:50:36 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/5f3paTCWzzvt4ekVwLA6u1QnrdE Subject: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:51:10 -0000 We set up this list after the FCC numbering workshop earlier this year to s= ee if there's interest and an initial list of to-do's in modernizing E.164 = numbering delegation, porting, and lookup. I'd like to re-awaken this effor= t and see if we can make some initial progress. I see two fundamental technical discussions: (1) Architecture for managing numbers, along the centralized-to-distributed= spectrum (2) What protocol pieces are out there that can be re-used (WEIRDS? EPP?), = are they relevant and which ones are still needed? Henning From nobody Wed Oct 15 12:22:06 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512E81A9167 for ; Wed, 15 Oct 2014 12:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 KjMwMiFrTOE7 for ; Wed, 15 Oct 2014 12:22:04 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id D2AB11A9240 for ; Wed, 15 Oct 2014 12:22:01 -0700 (PDT) Received: (qmail 25484 invoked by uid 0); 15 Oct 2014 19:22:00 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 15 Oct 2014 19:22:00 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 3dMu1p00D1MNPNq01dMxW7; Wed, 15 Oct 2014 19:21:59 -0600 X-Authority-Analysis: v=2.1 cv=fdw+lSgF c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=bnHGOiKsDSOx3V67aDcA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=vRAbILRZcFsA:10 a=lZB815dzVvQA:10 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:Message-ID:To:From:Subject:Date; bh=rG/MdTf/lbd6o9SKSsp2vPwXpvkXTOj9VYjAvWF6E5E=; b=jsAoAaZtSkNRAuEcffOGkAeAcAwn7xBihfZSpIkJsrIjJbSX6lJLcKSEI9w8rvER8Tm/75WirfSNQeRmhFiwTArCfG1yDWQuWQN2NCGPbcDyRnkaNQVj1sNz6YnLtXoQ; Received: from [72.66.64.164] (port=54613 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeU8w-0006Gf-H8; Wed, 15 Oct 2014 13:21:54 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 15:21:49 -0400 From: Richard Shockey To: Henning Schulzrinne , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/x6RdFfMbmDjQHMqQxYKIRaHec78 Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:22:05 -0000 Well I=B9m delighted you brought up the subject. I could make up some really bad jokes about certain numbering committees .. During the FCC workshop I mentioned that years ago we had some consensus that EPP was not appropriate for the provisioning portion of the protocol problem statement. We set up IETF DRINKS in 08 specifically to look at the provisioning problem. EPP was set up for the sole purpose of serving the domain name industry, dealing with the ICANN requirements and as such was way carried a lot of baggage with it. In addition the carriers I spoke to were adamant they did not want any new protocol stack in their already insanely expensive OSS/BSS systems and they were all moving to something like HTTP SOAP or some RESTFUL like protocols XML or JSON defined schema=B9s. I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a failure for several reasons, principally timing. I really don=B9t think the industry was ready to revisit the numbering provisioning problem with a clean sheet of paper. Times change=8A attitudes change. I can assure you that the SIP Forum ATIS NNI workshop did in fact discuss what NGN numbering would look like in the post Transition phase and everyone is going to see the work in progress documents in a day or so. I=B9ll be posting a URL to the usual RAI lists. So again Henning your timing is excellent. =8B=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 On 10/15/14, 2:50 PM, "Henning Schulzrinne" wrote: >We set up this list after the FCC numbering workshop earlier this year to >see if there's interest and an initial list of to-do's in modernizing >E.164 numbering delegation, porting, and lookup. I'd like to re-awaken >this effort and see if we can make some initial progress. > >I see two fundamental technical discussions: > >(1) Architecture for managing numbers, along the >centralized-to-distributed spectrum > >(2) What protocol pieces are out there that can be re-used (WEIRDS? >EPP?), are they relevant and which ones are still needed? > >Henning > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Oct 15 12:47:31 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7947F1A7D80 for ; Wed, 15 Oct 2014 12:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dfbRO9iJCHHn for ; Wed, 15 Oct 2014 12:47:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2201A890B for ; Wed, 15 Oct 2014 12:47:26 -0700 (PDT) Received: from BN1AFFO11FD041.protection.gbl (10.58.52.32) by BN1AFFO11HUB043.protection.gbl (10.58.52.154) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Wed, 15 Oct 2014 19:47:24 +0000 Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by BN1AFFO11FD041.mail.protection.outlook.com (10.58.52.252) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 15 Oct 2014 19:47:24 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9FJlNUw012901 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 14:47:23 -0500 Received: from PREWE13M07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9FJlK4U012267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Oct 2014 14:47:22 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 15 Oct 2014 15:47:00 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Wed, 15 Oct 2014 14:47:00 -0500 From: "Gorman, Pierce A [NTK]" To: Richard Shockey , Henning Schulzrinne , "modern@ietf.org" Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Thread-Index: AQHP6K1ZoCfS2/9o7kWv1QsJak2URJwxjWvg Date: Wed, 15 Oct 2014 19:46:59 +0000 Message-ID: <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.229.32.56; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(24454002)(199003)(377454003)(479174003)(51704005)(189002)(76176999)(50986999)(54356999)(77096002)(106466001)(106116001)(31966008)(95666004)(26826002)(107046002)(107886001)(47776003)(20776003)(64706001)(6806004)(4396001)(19580395003)(19580405001)(44976005)(15974865002)(21056001)(92566001)(85852003)(86362001)(2656002)(87936001)(15975445006)(99396003)(2501002)(50466002)(85306004)(33646002)(108616004)(80022003)(46102003)(76482002)(120916001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB043; H:pdaasdm1.corp.sprint.com; FPR:; PTR:smtpda1.sprint.com; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB043; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0365C0E14B Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.56 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.56; helo=pdaasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.56) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/4jNY2T-UXJKm4ts00MUInIbgHLk Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:47:29 -0000 I'm awake! I'm awake! Richard and Henning, Has anyone discussed moving beyond DNS/ENUM? I=92m wondering if something = based on DIAMETER and XML might be a better long-term choice for routing in= formation management requirements. If you're familiar with work in this ar= ea (and I suspect there is), I'd be interested in looking at it. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: October 15, 2014 2:22 PM To: Henning Schulzrinne; modern@ietf.org Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies Well I=B9m delighted you brought up the subject. I could make up some real= ly bad jokes about certain numbering committees .. During the FCC workshop I mentioned that years ago we had some consensus th= at EPP was not appropriate for the provisioning portion of the protocol pro= blem statement. We set up IETF DRINKS in 08 specifically to look at the provisioning proble= m. EPP was set up for the sole purpose of serving the domain name industry,= dealing with the ICANN requirements and as such was way carried a lot of b= aggage with it. In addition the carriers I spoke to were adamant they did not want any new = protocol stack in their already insanely expensive OSS/BSS systems and they= were all moving to something like HTTP SOAP or some RESTFUL like protocols= XML or JSON defined schema=B9s. I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a fai= lure for several reasons, principally timing. I really don=B9t think the in= dustry was ready to revisit the numbering provisioning problem with a clean= sheet of paper. Times change=D0 attitudes change. I can assure you that the SIP Forum ATIS= NNI workshop did in fact discuss what NGN numbering would look like in the= post Transition phase and everyone is going to see the work in progress do= cuments in a day or so. I=B9ll be posting a URL to the usual RAI lists. So = again Henning your timing is excellent. =8B 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/15/14, 2:50 PM, "Henning Schulzrinne" wrote: >We set up this list after the FCC numbering workshop earlier this year to >see if there's interest and an initial list of to-do's in modernizing >E.164 numbering delegation, porting, and lookup. I'd like to re-awaken >this effort and see if we can make some initial progress. > >I see two fundamental technical discussions: > >(1) Architecture for managing numbers, along the >centralized-to-distributed spectrum > >(2) What protocol pieces are out there that can be re-used (WEIRDS? >EPP?), are they relevant and which ones are still needed? > >Henning > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Oct 15 12:52:47 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB211A7005 for ; Wed, 15 Oct 2014 12:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 goJ7TxXeq41Y for ; Wed, 15 Oct 2014 12:52:43 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id B80931A1AC3 for ; Wed, 15 Oct 2014 12:52:42 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "modern@ietf.org" Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Thread-Index: AQHP6K1NhJZJKAxykkKZF53rVUlCq5wx00SA//+9rJI= Date: Wed, 15 Oct 2014 19:52:39 +0000 References: , <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> In-Reply-To: <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/3ls3mKdbUKVJm5fIT_XHmq-1Bk8 Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:52:46 -0000 There are probably several somewhat separate operations:=0A= =0A= * get mapping from number to SIP URL (classical ENUM territory)=0A= * mapping from number to "whois"-like information=0A= * managing assignment of numbers to end users and/or carriers, including po= rting=0A= =0A= They may have different needs. I suspect we don't want to cram a whole "who= is"-like response into a DNS answer.=0A= =0A= I'm less sure how DIAMETER would fit here, assuming we're talking about a A= AA-like application, rather than (ab)using DIAMETER as a generic query-resp= onse protocol.=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com]=0A= Sent: Wednesday, October 15, 2014 3:46 PM=0A= To: Richard Shockey; Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Almost Halloween - time to wake the numbering zombies= =0A= =0A= I'm awake! I'm awake!=0A= =0A= Richard and Henning,=0A= =0A= Has anyone discussed moving beyond DNS/ENUM? I=92m wondering if something = based on DIAMETER and XML might be a better long-term choice for routing in= formation management requirements. If you're familiar with work in this ar= ea (and I suspect there is), I'd be interested in looking at it.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Voice Architecture=0A= Core Planning/Sprint=0A= 913-439-4368 (Desk)=0A= =0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey= =0A= Sent: October 15, 2014 2:22 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies= =0A= =0A= =0A= Well I=B9m delighted you brought up the subject. I could make up some real= ly bad jokes about certain numbering committees ..=0A= =0A= During the FCC workshop I mentioned that years ago we had some consensus th= at EPP was not appropriate for the provisioning portion of the protocol pro= blem statement.=0A= =0A= We set up IETF DRINKS in 08 specifically to look at the provisioning proble= m. EPP was set up for the sole purpose of serving the domain name industry,= dealing with the ICANN requirements and as such was way carried a lot of b= aggage with it.=0A= =0A= In addition the carriers I spoke to were adamant they did not want any new = protocol stack in their already insanely expensive OSS/BSS systems and they= were all moving to something like HTTP SOAP or some RESTFUL like protocols= XML or JSON defined schema=B9s.=0A= =0A= I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a fai= lure for several reasons, principally timing. I really don=B9t think the in= dustry was ready to revisit the numbering provisioning problem with a clean= sheet of paper.=0A= =0A= Times change=8A attitudes change. I can assure you that the SIP Forum ATIS= NNI workshop did in fact discuss what NGN numbering would look like in the= post Transition phase and everyone is going to see the work in progress do= cuments in a day or so. I=B9ll be posting a URL to the usual RAI lists. So = again Henning your timing is excellent.=0A= =0A= =8B=0A= Richard Shockey=0A= Shockey Consulting LLC=0A= Chairman of the Board SIP Forum=0A= www.shockey.us=0A= Www.sipforum.org=0A= richardshockey.us=0A= Skype-Linkedin-Facebook rshockey101=0A= PSTN +1 703-593-2683=0A= =0A= =0A= =0A= =0A= =0A= On 10/15/14, 2:50 PM, "Henning Schulzrinne" = =0A= wrote:=0A= =0A= >We set up this list after the FCC numbering workshop earlier this year to= =0A= >see if there's interest and an initial list of to-do's in modernizing=0A= >E.164 numbering delegation, porting, and lookup. I'd like to re-awaken=0A= >this effort and see if we can make some initial progress.=0A= >=0A= >I see two fundamental technical discussions:=0A= >=0A= >(1) Architecture for managing numbers, along the=0A= >centralized-to-distributed spectrum=0A= >=0A= >(2) What protocol pieces are out there that can be re-used (WEIRDS?=0A= >EPP?), are they relevant and which ones are still needed?=0A= >=0A= >Henning=0A= >=0A= >_______________________________________________=0A= >Modern mailing list=0A= >Modern@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/modern=0A= =0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= =0A= From nobody Wed Oct 15 12:57:09 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4965E1A9231 for ; Wed, 15 Oct 2014 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ruemN7u2BOgj for ; Wed, 15 Oct 2014 12:57:04 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0BA1A90D3 for ; Wed, 15 Oct 2014 12:57:03 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "modern@ietf.org" Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Thread-Index: AQHP6K1NhJZJKAxykkKZF53rVUlCq5wx00SA//+9rJKAAAEZxg== Date: Wed, 15 Oct 2014 19:57:01 +0000 References: , <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Blbxr8Mukw39-gT6tC2FpAZVgP0 Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 19:57:07 -0000 I have no particular emotional attachment to EPP, but in the interest of le= arning from history, could you be more specific about its "baggage"?=0A= =0A= After all, EPP uses XML and seems simpler than SOAP. (We can have the usual= JSON-vs-XML debate, but that seems like a second-order issue, as much fun = as the binary-vs-text debates that we used to have on IETF lists.)=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Henning Schulzrinne [He= nning.Schulzrinne@fcc.gov]=0A= Sent: Wednesday, October 15, 2014 3:52 PM=0A= To: modern@ietf.org=0A= Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies= =0A= =0A= There are probably several somewhat separate operations:=0A= =0A= * get mapping from number to SIP URL (classical ENUM territory)=0A= * mapping from number to "whois"-like information=0A= * managing assignment of numbers to end users and/or carriers, including po= rting=0A= =0A= They may have different needs. I suspect we don't want to cram a whole "who= is"-like response into a DNS answer.=0A= =0A= I'm less sure how DIAMETER would fit here, assuming we're talking about a A= AA-like application, rather than (ab)using DIAMETER as a generic query-resp= onse protocol.=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com]=0A= Sent: Wednesday, October 15, 2014 3:46 PM=0A= To: Richard Shockey; Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Almost Halloween - time to wake the numbering zombies= =0A= =0A= I'm awake! I'm awake!=0A= =0A= Richard and Henning,=0A= =0A= Has anyone discussed moving beyond DNS/ENUM? I=92m wondering if something = based on DIAMETER and XML might be a better long-term choice for routing in= formation management requirements. If you're familiar with work in this ar= ea (and I suspect there is), I'd be interested in looking at it.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Voice Architecture=0A= Core Planning/Sprint=0A= 913-439-4368 (Desk)=0A= =0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey= =0A= Sent: October 15, 2014 2:22 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies= =0A= =0A= =0A= Well I=B9m delighted you brought up the subject. I could make up some real= ly bad jokes about certain numbering committees ..=0A= =0A= During the FCC workshop I mentioned that years ago we had some consensus th= at EPP was not appropriate for the provisioning portion of the protocol pro= blem statement.=0A= =0A= We set up IETF DRINKS in 08 specifically to look at the provisioning proble= m. EPP was set up for the sole purpose of serving the domain name industry,= dealing with the ICANN requirements and as such was way carried a lot of b= aggage with it.=0A= =0A= In addition the carriers I spoke to were adamant they did not want any new = protocol stack in their already insanely expensive OSS/BSS systems and they= were all moving to something like HTTP SOAP or some RESTFUL like protocols= XML or JSON defined schema=B9s.=0A= =0A= I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a fai= lure for several reasons, principally timing. I really don=B9t think the in= dustry was ready to revisit the numbering provisioning problem with a clean= sheet of paper.=0A= =0A= Times change=8A attitudes change. I can assure you that the SIP Forum ATIS= NNI workshop did in fact discuss what NGN numbering would look like in the= post Transition phase and everyone is going to see the work in progress do= cuments in a day or so. I=B9ll be posting a URL to the usual RAI lists. So = again Henning your timing is excellent.=0A= =0A= =8B=0A= Richard Shockey=0A= Shockey Consulting LLC=0A= Chairman of the Board SIP Forum=0A= www.shockey.us=0A= Www.sipforum.org=0A= richardshockey.us=0A= Skype-Linkedin-Facebook rshockey101=0A= PSTN +1 703-593-2683=0A= =0A= =0A= =0A= =0A= =0A= On 10/15/14, 2:50 PM, "Henning Schulzrinne" = =0A= wrote:=0A= =0A= >We set up this list after the FCC numbering workshop earlier this year to= =0A= >see if there's interest and an initial list of to-do's in modernizing=0A= >E.164 numbering delegation, porting, and lookup. I'd like to re-awaken=0A= >this effort and see if we can make some initial progress.=0A= >=0A= >I see two fundamental technical discussions:=0A= >=0A= >(1) Architecture for managing numbers, along the=0A= >centralized-to-distributed spectrum=0A= >=0A= >(2) What protocol pieces are out there that can be re-used (WEIRDS?=0A= >EPP?), are they relevant and which ones are still needed?=0A= >=0A= >Henning=0A= >=0A= >_______________________________________________=0A= >Modern mailing list=0A= >Modern@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/modern=0A= =0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= =0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= From nobody Wed Oct 15 13:08:00 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59E61AC444 for ; Wed, 15 Oct 2014 13:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QgrP_HybSJ7e for ; Wed, 15 Oct 2014 13:07:46 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63EC41A8940 for ; Wed, 15 Oct 2014 13:07:36 -0700 (PDT) Received: from BY2FFO11FD020.protection.gbl (10.1.14.34) by BY2FFO11HUB045.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Wed, 15 Oct 2014 19:58:57 +0000 Received: from plsasdm1.corp.sprint.com (144.230.168.25) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 15 Oct 2014 19:58:57 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9FJwu3g016601 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2014 14:58:56 -0500 Received: from PLSWE13M08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9FJwu0g022012 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Oct 2014 14:58:56 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 15 Oct 2014 14:58:55 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Wed, 15 Oct 2014 14:58:55 -0500 From: "Gorman, Pierce A [NTK]" To: Henning Schulzrinne , "modern@ietf.org" Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Thread-Index: AQHP6K1ZoCfS2/9o7kWv1QsJak2URJwxjWvggABYMYD//6y2UA== Date: Wed, 15 Oct 2014 19:58:55 +0000 Message-ID: References: , <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.168.25; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(51704005)(13464003)(24454002)(199003)(377454003)(479174003)(44976005)(19580405001)(120916001)(108616004)(106466001)(54356999)(76176999)(50986999)(26826002)(15974865002)(99396003)(15975445006)(2656002)(2501002)(87936001)(64706001)(86362001)(19580395003)(85852003)(4396001)(6806004)(85306004)(92566001)(76482002)(20776003)(47776003)(33646002)(107886001)(107046002)(77096002)(80022003)(46102003)(106116001)(50466002)(21056001)(95666004)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB045; H:plsasdm1.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpls1.sprint.com; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB045; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0365C0E14B Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.25 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.25; helo=plsasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.25) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/CLZTasN1Xzx0jui1o7xTzM6W5v8 Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:07:52 -0000 Nope, I was thinking of (ab)using DIAMETER as a generic query-response prot= ocol. The little, tiny, submission I was responsible for in the ATIS/SIP F= orum JTF report was with regard to classical ENUM being woefully inadequate= in terms of routing calls other than those which have no requirements for = source information. E.g., location. There are numerous call types which u= se location. E.g., local, long-distance, toll-free, emergency services. A= nd that is just one piece of information about the source. Credentials and= other pieces of information such as user service capabilities might be imp= ortant. Can you accept a video call? Are you allowed to call the POTUS? Anyway a little giddy before Halloween, but definitely dissatisfied with cl= assical ENUM and DNS for call routing. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: October 15, 2014 2:53 PM To: modern@ietf.org Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies There are probably several somewhat separate operations: * get mapping from number to SIP URL (classical ENUM territory) * mapping from number to "whois"-like information * managing assignment of numbers to end users and/or carriers, including po= rting They may have different needs. I suspect we don't want to cram a whole "who= is"-like response into a DNS answer. I'm less sure how DIAMETER would fit here, assuming we're talking about a A= AA-like application, rather than (ab)using DIAMETER as a generic query-resp= onse protocol. ________________________________________ From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com] Sent: Wednesday, October 15, 2014 3:46 PM To: Richard Shockey; Henning Schulzrinne; modern@ietf.org Subject: RE: [Modern] Almost Halloween - time to wake the numbering zombies I'm awake! I'm awake! Richard and Henning, Has anyone discussed moving beyond DNS/ENUM? I=92m wondering if something = based on DIAMETER and XML might be a better long-term choice for routing in= formation management requirements. If you're familiar with work in this ar= ea (and I suspect there is), I'd be interested in looking at it. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey Sent: October 15, 2014 2:22 PM To: Henning Schulzrinne; modern@ietf.org Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies Well I=B9m delighted you brought up the subject. I could make up some real= ly bad jokes about certain numbering committees .. During the FCC workshop I mentioned that years ago we had some consensus th= at EPP was not appropriate for the provisioning portion of the protocol pro= blem statement. We set up IETF DRINKS in 08 specifically to look at the provisioning proble= m. EPP was set up for the sole purpose of serving the domain name industry,= dealing with the ICANN requirements and as such was way carried a lot of b= aggage with it. In addition the carriers I spoke to were adamant they did not want any new = protocol stack in their already insanely expensive OSS/BSS systems and they= were all moving to something like HTTP SOAP or some RESTFUL like protocols= XML or JSON defined schema=B9s. I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a fai= lure for several reasons, principally timing. I really don=B9t think the in= dustry was ready to revisit the numbering provisioning problem with a clean= sheet of paper. Times change=D0 attitudes change. I can assure you that the SIP Forum ATIS= NNI workshop did in fact discuss what NGN numbering would look like in the= post Transition phase and everyone is going to see the work in progress do= cuments in a day or so. I=B9ll be posting a URL to the usual RAI lists. So = again Henning your timing is excellent. =8B 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/15/14, 2:50 PM, "Henning Schulzrinne" wrote: >We set up this list after the FCC numbering workshop earlier this year >to see if there's interest and an initial list of to-do's in >modernizing >E.164 numbering delegation, porting, and lookup. I'd like to re-awaken >this effort and see if we can make some initial progress. > >I see two fundamental technical discussions: > >(1) Architecture for managing numbers, along the >centralized-to-distributed spectrum > >(2) What protocol pieces are out there that can be re-used (WEIRDS? >EPP?), are they relevant and which ones are still needed? > >Henning > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Wed Oct 15 13:18:39 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4951A88CD for ; Wed, 15 Oct 2014 13:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.567 X-Spam-Level: X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 a2_48q-h5rdr for ; Wed, 15 Oct 2014 13:18:35 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 030171A879F for ; Wed, 15 Oct 2014 13:18:34 -0700 (PDT) Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s9FKIUg1008195; Wed, 15 Oct 2014 16:18:32 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1q1ww7r83s-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Oct 2014 16:18:30 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 15 Oct 2014 16:18:07 -0400 From: "Peterson, Jon" To: "Gorman, Pierce A [NTK]" Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Thread-Index: AQHP6K1SQIFi+ccl7UuBbC3E9hKOd5wx00SAgAABlYCAAAHAgP//wk9j Date: Wed, 15 Oct 2014 20:18:06 +0000 Message-ID: References: , <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7592 signatures=670547 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=7.7715611723761e-16 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999499320145558 urlsuspect_oldscore=0.999499320145558 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.999499320145558 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410150176 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/mdFI9N4Y55LaPaxYEN9mb1V7HlY Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:18:37 -0000 Certainly DIAMETER was one of the target protocols considered for the TeRQ = framework: http://www.ietf.org/archive/id/draft-peterson-terq-03.txt For various reasons, TeRQ took a backseat to STIR, but as the initial STIR = work winds down, we may want to revisit some of these ideas.=20 Jon Peterson Neustar, Inc. Sent from my iPad > On Oct 15, 2014, at 1:08 PM, "Gorman, Pierce A [NTK]" wrote: >=20 > Nope, I was thinking of (ab)using DIAMETER as a generic query-response pr= otocol. The little, tiny, submission I was responsible for in the ATIS/SIP= Forum JTF report was with regard to classical ENUM being woefully inadequa= te in terms of routing calls other than those which have no requirements fo= r source information. E.g., location. There are numerous call types which= use location. E.g., local, long-distance, toll-free, emergency services. = And that is just one piece of information about the source. Credentials a= nd other pieces of information such as user service capabilities might be i= mportant. Can you accept a video call? Are you allowed to call the POTUS? >=20 > Anyway a little giddy before Halloween, but definitely dissatisfied with = classical ENUM and DNS for call routing. >=20 > Best regards, >=20 >=20 > Pierce Gorman > Voice Architecture > Core Planning/Sprint > 913-439-4368 (Desk) >=20 >=20 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulz= rinne > Sent: October 15, 2014 2:53 PM > To: modern@ietf.org > Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombi= es >=20 > There are probably several somewhat separate operations: >=20 > * get mapping from number to SIP URL (classical ENUM territory) > * mapping from number to "whois"-like information > * managing assignment of numbers to end users and/or carriers, including = porting >=20 > They may have different needs. I suspect we don't want to cram a whole "w= hois"-like response into a DNS answer. >=20 > I'm less sure how DIAMETER would fit here, assuming we're talking about a= AAA-like application, rather than (ab)using DIAMETER as a generic query-re= sponse protocol. >=20 > ________________________________________ > From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com] > Sent: Wednesday, October 15, 2014 3:46 PM > To: Richard Shockey; Henning Schulzrinne; modern@ietf.org > Subject: RE: [Modern] Almost Halloween - time to wake the numbering zombi= es >=20 > I'm awake! I'm awake! >=20 > Richard and Henning, >=20 > Has anyone discussed moving beyond DNS/ENUM? I=92m wondering if somethin= g based on DIAMETER and XML might be a better long-term choice for routing = information management requirements. If you're familiar with work in this = area (and I suspect there is), I'd be interested in looking at it. >=20 > Best regards, >=20 >=20 > Pierce Gorman > Voice Architecture > Core Planning/Sprint > 913-439-4368 (Desk) >=20 >=20 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shocke= y > Sent: October 15, 2014 2:22 PM > To: Henning Schulzrinne; modern@ietf.org > Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombi= es >=20 >=20 > Well I=B9m delighted you brought up the subject. I could make up some re= ally bad jokes about certain numbering committees .. >=20 > During the FCC workshop I mentioned that years ago we had some consensus = that EPP was not appropriate for the provisioning portion of the protocol p= roblem statement. >=20 > We set up IETF DRINKS in 08 specifically to look at the provisioning prob= lem. EPP was set up for the sole purpose of serving the domain name industr= y, dealing with the ICANN requirements and as such was way carried a lot of= baggage with it. >=20 > In addition the carriers I spoke to were adamant they did not want any ne= w protocol stack in their already insanely expensive OSS/BSS systems and th= ey were all moving to something like HTTP SOAP or some RESTFUL like protoco= ls XML or JSON defined schema=B9s. >=20 > I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a f= ailure for several reasons, principally timing. I really don=B9t think the = industry was ready to revisit the numbering provisioning problem with a cle= an sheet of paper. >=20 > Times change=8A attitudes change. I can assure you that the SIP Forum AT= IS NNI workshop did in fact discuss what NGN numbering would look like in t= he post Transition phase and everyone is going to see the work in progress = documents in a day or so. I=B9ll be posting a URL to the usual RAI lists. S= o again Henning your timing is excellent. >=20 > =8B > 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 >=20 >=20 >=20 > On 10/15/14, 2:50 PM, "Henning Schulzrinne" > wrote: >=20 >> We set up this list after the FCC numbering workshop earlier this year >> to see if there's interest and an initial list of to-do's in >> modernizing >> E.164 numbering delegation, porting, and lookup. I'd like to re-awaken >> this effort and see if we can make some initial progress. >>=20 >> I see two fundamental technical discussions: >>=20 >> (1) Architecture for managing numbers, along the >> centralized-to-distributed spectrum >>=20 >> (2) What protocol pieces are out there that can be re-used (WEIRDS? >> EPP?), are they relevant and which ones are still needed? >>=20 >> Henning >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 > ________________________________ >=20 > This e-mail may contain Sprint proprietary information intended for the s= ole use of the recipient(s). Any use by others is prohibited. If you are no= t the intended recipient, please contact the sender and delete all copies o= f the message. >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Wed Oct 15 13:26:20 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84E21ACCE0 for ; Wed, 15 Oct 2014 13:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 EcPmRSp0XFzX for ; Wed, 15 Oct 2014 13:26:17 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id E6CBE1ACCD8 for ; Wed, 15 Oct 2014 13:26:16 -0700 (PDT) Received: (qmail 31630 invoked by uid 0); 15 Oct 2014 20:26:13 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 15 Oct 2014 20:26:13 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 3eS71p01B1MNPNq01eSAdi; Wed, 15 Oct 2014 20:26:12 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=QWaE5fiKRrkNnT-q3g4A:9 a=gdCz8nHnA5_oRGrd:21 a=U0yGnjGQzl1iKWlJ:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 a=ivbTfD_dPm4A:10 a=2aF6lfeD-CsA:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA:10 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=XvLV4XV3E9+vJYlXw7OIpV2wLgngBCVxkt2rofB//a8=; b=KrUHFNXm8HH972gRNNA59zdH92g8gtwKzfXjIXqnwS5uodkxEcuIEDGKlSfkgLFdcGVRp0Jaz94hNBFg/WAZS4gST4X1LQsLOcxpl/R64nhRlShPSJ5gChJhMII5G5+C; Received: from [72.66.64.164] (port=54727 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeV96-00074O-HI; Wed, 15 Oct 2014 14:26:08 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 16:26:03 -0400 From: Richard Shockey To: "Gorman, Pierce A [NTK]" , Henning Schulzrinne , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies References: <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/M9X_bGqH7cTFkVYMUFidY9w7UbE Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:26:19 -0000 They=E2=80=99re alive ! They=E2=80=99re alive! Well Pierce .. I certainly want to make it perfectly clear that if the ENUM WG knew what we knew now we would not have gone down the DNS route. I had enough problems beating back the X.500 zombies. We selected the best available technology we had available at the time and for all of its endless faults (and you know I can list them) it does work and work well so far. That said rethinking the whole problem is certainly in order here. Determinate response.. Service capability hints certainly security mechanisms STIR PKI CNAM + etc. Peterson had a excellent draft on some of this. On 10/15/14, 3:58 PM, "Gorman, Pierce A [NTK]" wrote: >Nope, I was thinking of (ab)using DIAMETER as a generic query-response >protocol. The little, tiny, submission I was responsible for in the >ATIS/SIP Forum JTF report was with regard to classical ENUM being >woefully inadequate in terms of routing calls other than those which have >no requirements for source information. E.g., location. There are >numerous call types which use location. E.g., local, long-distance, >toll-free, emergency services. And that is just one piece of information >about the source. Credentials and other pieces of information such as >user service capabilities might be important. Can you accept a video >call? Are you allowed to call the POTUS? > >Anyway a little giddy before Halloween, but definitely dissatisfied with >classical ENUM and DNS for call routing. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >Schulzrinne >Sent: October 15, 2014 2:53 PM >To: modern@ietf.org >Subject: Re: [Modern] Almost Halloween - time to wake the numbering >zombies > >There are probably several somewhat separate operations: > >* get mapping from number to SIP URL (classical ENUM territory) >* mapping from number to "whois"-like information >* managing assignment of numbers to end users and/or carriers, including >porting > >They may have different needs. I suspect we don't want to cram a whole >"whois"-like response into a DNS answer. > >I'm less sure how DIAMETER would fit here, assuming we're talking about a >AAA-like application, rather than (ab)using DIAMETER as a generic >query-response protocol. > >________________________________________ >From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com] >Sent: Wednesday, October 15, 2014 3:46 PM >To: Richard Shockey; Henning Schulzrinne; modern@ietf.org >Subject: RE: [Modern] Almost Halloween - time to wake the numbering >zombies > >I'm awake! I'm awake! > >Richard and Henning, > >Has anyone discussed moving beyond DNS/ENUM? I=E2=80=99m wondering if something >based on DIAMETER and XML might be a better long-term choice for routing >information management requirements. If you're familiar with work in >this area (and I suspect there is), I'd be interested in looking at it. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: October 15, 2014 2:22 PM >To: Henning Schulzrinne; modern@ietf.org >Subject: Re: [Modern] Almost Halloween - time to wake the numbering >zombies > > >Well I=C2=B9m delighted you brought up the subject. I could make up some >really bad jokes about certain numbering committees .. > >During the FCC workshop I mentioned that years ago we had some consensus >that EPP was not appropriate for the provisioning portion of the protocol >problem statement. > >We set up IETF DRINKS in 08 specifically to look at the provisioning >problem. EPP was set up for the sole purpose of serving the domain name >industry, dealing with the ICANN requirements and as such was way carried >a lot of baggage with it. > >In addition the carriers I spoke to were adamant they did not want any >new protocol stack in their already insanely expensive OSS/BSS systems >and they were all moving to something like HTTP SOAP or some RESTFUL like >protocols XML or JSON defined schema=C2=B9s. > >I=C2=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a >failure for several reasons, principally timing. I really don=C2=B9t think the >industry was ready to revisit the numbering provisioning problem with a >clean sheet of paper. > >Times change=C5=A0 attitudes change. I can assure you that the SIP Forum ATIS >NNI workshop did in fact discuss what NGN numbering would look like in >the post Transition phase and everyone is going to see the work in >progress documents in a day or so. I=C2=B9ll be posting a URL to the usual RAI >lists. So again Henning your timing is excellent. > >=E2=80=B9 >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/15/14, 2:50 PM, "Henning Schulzrinne" >wrote: > >>We set up this list after the FCC numbering workshop earlier this year >>to see if there's interest and an initial list of to-do's in >>modernizing >>E.164 numbering delegation, porting, and lookup. I'd like to re-awaken >>this effort and see if we can make some initial progress. >> >>I see two fundamental technical discussions: >> >>(1) Architecture for managing numbers, along the >>centralized-to-distributed spectrum >> >>(2) What protocol pieces are out there that can be re-used (WEIRDS? >>EPP?), are they relevant and which ones are still needed? >> >>Henning >> >>_______________________________________________ >>Modern mailing list >>Modern@ietf.org >>https://www.ietf.org/mailman/listinfo/modern > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Oct 15 13:35:26 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E31ACD3C for ; Wed, 15 Oct 2014 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 jzOJSYlrs3wC for ; Wed, 15 Oct 2014 13:35:22 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 3FFA61ACD1E for ; Wed, 15 Oct 2014 13:35:06 -0700 (PDT) Received: (qmail 25302 invoked by uid 0); 15 Oct 2014 20:35:05 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy3.mail.unifiedlayer.com with SMTP; 15 Oct 2014 20:35:05 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 3Yb11p00j1MNPNq01Yb4JN; Wed, 15 Oct 2014 14:35:04 -0600 X-Authority-Analysis: v=2.1 cv=Tr912lnh c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=48vgC7mUAAAA:8 a=izV7ms69AAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=QWaE5fiKRrkNnT-q3g4A:9 a=F_SdrUKW1qc386bx:21 a=-q1tVtoQZN5VF0gq:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 a=ivbTfD_dPm4A:10 a=lZB815dzVvQA:10 a=2aF6lfeD-CsA:10 a=vRAbILRZcFsA:10 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=Jm+r77y5nGUpQ/77SKlEaq2tedc97uFeNR4l5ek/GOk=; b=XWdFjYFPvWL7ctS8r8FEkqnoRPTz/QAmeDttfW14MXfRDQ5yFWt4apY+5jOsBU8IbcXTU6I+JynwZH38hmdUruelGB3q+rVMyDZPSaENAzAodUoeByAXOyfWgrsbXa+L; Received: from [72.66.64.164] (port=54728 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeVHh-0007bg-9F; Wed, 15 Oct 2014 14:35:02 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 16:34:56 -0400 From: Richard Shockey To: Henning Schulzrinne , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies References: <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/7H82XurkvQJOnS2BBK4Ra_YWgcQ Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:35:24 -0000 The baggage is dealing with the OSS/BSS systems in carrier voice networks. EPP as a theory is fine but it would be next to impossible to get a different transport stack in those systems. Ask a carrier what it takes to get a change order in one of these products and you will hear endless tales of woe and rent extraction. Frankly EPP was a failure as a IETF protocol since it was not really designed to be a generic system provisioning protocol. Money is the answer what is the question? TM Plus I agree JSON vs XML is a second order problem but comes up .. There are a lot of interesting discussions in the DRINKS archives about this but there is really no need to go too far back there. On 10/15/14, 3:57 PM, "Henning Schulzrinne" wrote: >I have no particular emotional attachment to EPP, but in the interest of >learning from history, could you be more specific about its "baggage"? > >After all, EPP uses XML and seems simpler than SOAP. (We can have the >usual JSON-vs-XML debate, but that seems like a second-order issue, as >much fun as the binary-vs-text debates that we used to have on IETF >lists.) > >________________________________________ >From: Modern [modern-bounces@ietf.org] on behalf of Henning Schulzrinne >[Henning.Schulzrinne@fcc.gov] >Sent: Wednesday, October 15, 2014 3:52 PM >To: modern@ietf.org >Subject: Re: [Modern] Almost Halloween - time to wake the numbering >zombies > >There are probably several somewhat separate operations: > >* get mapping from number to SIP URL (classical ENUM territory) >* mapping from number to "whois"-like information >* managing assignment of numbers to end users and/or carriers, including >porting > >They may have different needs. I suspect we don't want to cram a whole >"whois"-like response into a DNS answer. > >I'm less sure how DIAMETER would fit here, assuming we're talking about a >AAA-like application, rather than (ab)using DIAMETER as a generic >query-response protocol. > >________________________________________ >From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com] >Sent: Wednesday, October 15, 2014 3:46 PM >To: Richard Shockey; Henning Schulzrinne; modern@ietf.org >Subject: RE: [Modern] Almost Halloween - time to wake the numbering >zombies > >I'm awake! I'm awake! > >Richard and Henning, > >Has anyone discussed moving beyond DNS/ENUM? I=E2=80=99m wondering if something >based on DIAMETER and XML might be a better long-term choice for routing >information management requirements. If you're familiar with work in >this area (and I suspect there is), I'd be interested in looking at it. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: October 15, 2014 2:22 PM >To: Henning Schulzrinne; modern@ietf.org >Subject: Re: [Modern] Almost Halloween - time to wake the numbering >zombies > > >Well I=C2=B9m delighted you brought up the subject. I could make up some >really bad jokes about certain numbering committees .. > >During the FCC workshop I mentioned that years ago we had some consensus >that EPP was not appropriate for the provisioning portion of the protocol >problem statement. > >We set up IETF DRINKS in 08 specifically to look at the provisioning >problem. EPP was set up for the sole purpose of serving the domain name >industry, dealing with the ICANN requirements and as such was way carried >a lot of baggage with it. > >In addition the carriers I spoke to were adamant they did not want any >new protocol stack in their already insanely expensive OSS/BSS systems >and they were all moving to something like HTTP SOAP or some RESTFUL like >protocols XML or JSON defined schema=C2=B9s. > >I=C2=B9m pretty sure that sentiment has not changed. DRINKS as a WG was a >failure for several reasons, principally timing. I really don=C2=B9t think the >industry was ready to revisit the numbering provisioning problem with a >clean sheet of paper. > >Times change=C5=A0 attitudes change. I can assure you that the SIP Forum ATIS >NNI workshop did in fact discuss what NGN numbering would look like in >the post Transition phase and everyone is going to see the work in >progress documents in a day or so. I=C2=B9ll be posting a URL to the usual RAI >lists. So again Henning your timing is excellent. > >=E2=80=B9 >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/15/14, 2:50 PM, "Henning Schulzrinne" >wrote: > >>We set up this list after the FCC numbering workshop earlier this year to >>see if there's interest and an initial list of to-do's in modernizing >>E.164 numbering delegation, porting, and lookup. I'd like to re-awaken >>this effort and see if we can make some initial progress. >> >>I see two fundamental technical discussions: >> >>(1) Architecture for managing numbers, along the >>centralized-to-distributed spectrum >> >>(2) What protocol pieces are out there that can be re-used (WEIRDS? >>EPP?), are they relevant and which ones are still needed? >> >>Henning >> >>_______________________________________________ >>Modern mailing list >>Modern@ietf.org >>https://www.ietf.org/mailman/listinfo/modern > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Wed Oct 15 13:40:18 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBB81ACD05 for ; Wed, 15 Oct 2014 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DzD4G4IoSmKw for ; Wed, 15 Oct 2014 13:40:14 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 226921ACCEA for ; Wed, 15 Oct 2014 13:40:14 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , "modern@ietf.org" Thread-Topic: [Modern] EPP Thread-Index: AQHP6Lg4KqZ3FoFi4EetELK/8Qcwww== Date: Wed, 15 Oct 2014 20:40:12 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/t1gvQKNP13RSbWAjAgZT78wcHfg Subject: Re: [Modern] EPP X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:40:16 -0000 My sense is that any numbering OSS development will need code development, = since the process will presumably differ from the current model, particular= ly if we allow consumers (and other end users) to "rent" numbers. Anything-= over-HTTP is just invoking a library, so I'm not sure I understand the trad= e-off. Or are you suggesting that the new mechanism needs to be fully backw= ards-compatible with the current Neustar LNPA and other APIs?=0A= =0A= ________________________________________=0A= From: Richard Shockey [richard@shockey.us]=0A= Sent: Wednesday, October 15, 2014 4:34 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies= =0A= =0A= The baggage is dealing with the OSS/BSS systems in carrier voice networks.= =0A= EPP as a theory is fine but it would be next to impossible to get a=0A= different transport stack in those systems. Ask a carrier what it takes to= =0A= get a change order in one of these products and you will hear endless=0A= tales of woe and rent extraction.=0A= =0A= Frankly EPP was a failure as a IETF protocol since it was not really=0A= designed to be a generic system provisioning protocol.=0A= =0A= Money is the answer what is the question? TM=0A= =0A= Plus I agree JSON vs XML is a second order problem but comes up .. There=0A= are a lot of interesting discussions in the DRINKS archives about this but= =0A= there is really no need to go too far back there.= From nobody Wed Oct 15 13:42:56 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0356E1ACCEE for ; Wed, 15 Oct 2014 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 o8-5G0oH_PXu for ; Wed, 15 Oct 2014 13:42:51 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id AA4961A88F3 for ; Wed, 15 Oct 2014 13:42:51 -0700 (PDT) Received: (qmail 16783 invoked by uid 0); 15 Oct 2014 20:42:51 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 15 Oct 2014 20:42:51 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 3Yij1p00l1MNPNq01YimyK; Wed, 15 Oct 2014 14:42:50 -0600 X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=48vgC7mUAAAA:8 a=doUQZJtgAAAA:8 a=9bOKTyGbAAAA:8 a=M0OflfRGAAAA:8 a=ll-iCDY8AAAA:8 a=hea1mOaGJMCzGTMmGbgA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=5eIJMYd8ObsA:10 a=yDlVmugRoooA:10 a=GBsgy2rA9acA:10 a=0CJEY8SJ_7AA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=vRAbILRZcFsA:10 a=lZB815dzVvQA:10 a=Yo_weSMKip8A:10 a=N3zA0ylTc-fSNlXY1MkA:9 a=z4HL4pCmjvZ_gqSv:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=AML2GuDo7y+/9EwyqZ5yscQxYbPoHPifuYB08yHju9I=; b=UgOJjy8kbBnhwkKnRjEBRAq3a1p4t3IL8HUNvLBgrecOcZ9brVbPywwKD1Qe1LzctMZPJ+vvCc6+jnhteaA1bNtQYqgTEmXaAvb10xWzERymCrLye2MbTIxK5wptWZPC; Received: from [72.66.64.164] (port=54736 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeVPA-0007f6-1N for modern@ietf.org; Wed, 15 Oct 2014 14:42:44 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 16:42:39 -0400 From: Richard Shockey To: "modern@ietf.org" Message-ID: Thread-Topic: [dispatch] ATIS and SIP Forum Network to Network Interface work in progress documents Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3496236163_987436" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Nv3_BjvDb26GCy7FC6o3JZ3-uGY Subject: [Modern] FW: [dispatch] ATIS and SIP Forum Network to Network Interface work in progress documents X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:42:55 -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_3496236163_987436 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable FYI for those of you that haven=B9t seen this yet=8A this is why this conversation is so timely. We just released this today. It is ultimately central to the Interconnection routing problem. From: Richard Shockey Date: Wednesday, October 15, 2014 at 4:12 PM To: , , Subject: [dispatch] ATIS and SIP Forum Network to Network Interface work i= n progress documents As some of you know the SIP Forum and ATIS have been cooperating for the past year on a series of profile documents for SIP to facilitate all IP interconnection among service providers. The Task Force has agreed to make a snapshot of the documents available to the larger carrier and SIP community to invite informed technical comments. These are still a =B3work in progress=B2 . For those of you in the United States this work has taken on a larger significance since it has the attention of the United States Federal Communications Commission as was called out in a recent speech by Commissio= n Chairman Tom Wheeler. https://apps.fcc.gov/edocs_public/attachmatch/DOC-329767A1.pdf ****** The IP-Network to Network Interface (NNI) Joint Task Force , a cooperative effort between the ATIS and the SIP Forum, is seeking public comment on two draft documents: =20 1. IP Interconnection Profile. The IP-NNI Profile Specification defines a reference architectureand specifications for both the protocol an= d media as it appears =B3on-the-wire=B2 at interconnect points. The specifications reference commonly used IETF, 3GPP, and other related industry specifications and identify protocol extensions and capability information needed for all-IP telephony peering. 2. IP Interconnection Routing Report. The IP-NNI Routing Technical Report documents mechanisms for identifying the preferred IP interconnectio= n point for a given TN. This report presents multiple views of current IP interconnection mechanisms based on aggregate PSTN constructs, interim solutions based on all-IP routing using a per-TN registry, and a consideration of hybrid approaches across both mechanisms during the transition to all-IP. =20 Members of the IETF SIP Community may access the document directly here. http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,153/I= t emid,261/ Members of ATIS may also Access the documents at: http://access.atis.org/apps/org/workgroup/ipnni/download.php/18837/latest(f= o r ATIS members) or http://access.atis.org/apps/group_public/document.php?document_id=3D18837&wg_= a bbrev=3Dipnni (public access). =20 Providing Feedback: Written input, technical feedback only, is requested b= y October 29, 2014. However, in light of the short timeframe, input will be accepted until December 1, 2014. Submit comments to the Task Force via its mailing list. To do this, individuals must first be registered as a SIP Forum Participant Member (Free) here:http://www.sipforum.org/component/option,com_advanced_registration/tas= k ,register/.=20 When completed, subscription to the NNI Task Force mailing list can be performed at: http://sipforum.org/mailman/listinfo/nni. =20 For further information on the IP Network to Network Interface (NNI) Joint Task Force and these above-referenced documents, please contact me or Jim McEachern, Senior Technical Consultant, ATIS jmceachern@atis.org or me at the contact information listed below. =20 =8B=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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --B_3496236163_987436 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

FYI for those of you that haven’t seen this yet… this is= why this conversation is so timely.  We just released this today.

It is ultimately central to the Interconnection routing= problem.


Fro= m: Richard Shockey <richard@s= hockey.us>
Date: Wednesday,= October 15, 2014 at 4:12 PM
To: &= lt;dispatch@ietf.org>, <sipcore@ietf.org>, <rai@ietf.org>
Subject: <= /span> [dispatch] ATIS and SIP Forum Network to Network Interface work in pr= ogress documents


As some of you know the SIP Forum= and ATIS have been cooperating for the past year on a series of profile doc= uments for SIP to facilitate all IP interconnection among service providers.=


The Task Force has agreed to make a snapshot of the documents = available to the larger carrier and SIP community to invite informed technic= al comments.  These are still a “work in progress” .=

For those of= you in the United States this work has taken on a larger significance since= it has the attention of the United States Federal Communications Commission= as was called out in a recent speech by Commission Chairman Tom Wheeler.


https://apps.fcc.gov/edocs_public/attachmatch/D= OC-329767A1.pdf


 ******



The IP-Network to Network Interface (NNI) Joint Task Force, a coope= rative effort between the ATIS and the SIP Forum, is seeking public comment = on two draft documents:

 

1= .  &= nbsp;   IP Interconnectio= n Profile.  The IP-NNI Profile Speci= fication defines a reference architectureand specifications for both = the protocol and media as it appears “on-the-wire” at interconne= ct points.  The specifications reference commonly used IETF, 3GPP, and = other related industry specifications and identify protocol extensions and c= apability information needed for all-IP telephony peering.=

2.      IP Interconnection Routing Report. = ; The IP-NNI Routing Technical Report documents mechanisms for identifying t= he preferred IP interconnection point for a given TN. This report presents m= ultiple views of current IP interconnection mechanisms based on aggregate PS= TN constructs, interim solutions based on all-IP routing using a per-TN regi= stry, and a consideration of hybrid approaches across both mechanisms during= the transition to all-IP. 


 

Members of the IETF SIP Community may access th= e document directly here.


=


http://www.sipforum.org/component/option,com_docman/task,cat_vie= w/gid,153/Itemid,261/


=

Members of ATIS may = also Access the documents at: http://acc= ess.atis.org/apps/org/workgroup/ipnni/download.php/18837/latest(for ATIS= members) or

http://access.atis.org/a= pps/group_public/document.php?document_id=3D18837&wg_abbrev=3Dipnni = ;(public access).

 

<= p class=3D"Body" style=3D"font-family: 'Times New Roman', serif; margin: 0cm 0cm= 0.0001pt; font-size: 12pt; font-weight: normal;">Prov= iding Feedback:  Written input, t= echnical feedback only, is requested by October 29, 2014. However, = in light of the short timeframe, input will be accepted until December 1, 20= 14.  Submit comments to the Task Force via its mailing list. To do this= , individuals must first be registered as a SIP Forum Participant Member (Fr= ee) 


here:http://ww= w.sipforum.org/component/option,com_advanced_registration/task,register/= . 


 When completed, subscription to the NNI Task Force= mailing list can be performed at: http://sipforum.org/mailman/listinfo/n= ni.

 

For further inform= ation on the IP Network to Network Interface (NNI) Joint Task Force and thes= e above-referenced documents, please contact me or Jim McEachern, Senior Tec= hnical Consultant, ATIS jmceachern@atis.org or me at the contact information l= isted below.

 

= 212; 

Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
Www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshoc= key101
PSTN +1 = 703-593-2683

_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.o= rg/mailman/listinfo/dispatch --B_3496236163_987436-- From nobody Wed Oct 15 14:34:12 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A051ACDB7 for ; Wed, 15 Oct 2014 14:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_AMBIEN=0.552, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 RqRRDQXWWJA7 for ; Wed, 15 Oct 2014 14:34:09 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 35E071ACDBA for ; Wed, 15 Oct 2014 14:34:09 -0700 (PDT) Received: (qmail 3612 invoked by uid 0); 15 Oct 2014 21:34:04 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 15 Oct 2014 21:34:04 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 3fZz1p00C1MNPNq01fa21D; Wed, 15 Oct 2014 21:34:03 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N8cO2AP4qSUA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=48vgC7mUAAAA:8 a=0mYpZDy9s5UXztGkY5gA:9 a=wPNLvfGTeEIA:10 a=vRAbILRZcFsA:10 a=lZB815dzVvQA:10 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:Message-ID:To:From:Subject:Date; bh=JCEkvDHzEf6GdqoOr9YOmuCzxcOLquDBTVf/T2mIecY=; b=PiyxBouN6DpjmARt8mZ9fdCi+XC3en5l6S+pe/r8wySv+LxmtMX58pLH8e6k2u14/fmTC/AR9Kbg4046pEgJLugYyYRh0tq43wDNeHcO5BZ3oV1RIRL98Q2rNFqLuKdC; Received: from [72.66.64.164] (port=54787 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XeWCl-0001Ci-Bn; Wed, 15 Oct 2014 15:34:00 -0600 User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 15 Oct 2014 17:33:54 -0400 From: Richard Shockey To: Henning Schulzrinne , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Zombie numbering issues Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/smdEkd_osVF8fKIpZtZzCQ4eD3Q Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 21:34:10 -0000 On 10/15/14, 4:40 PM, "Henning Schulzrinne" wrote: >My sense is that any numbering OSS development will need code >development, since the process will presumably differ from the current >model, particularly if we allow consumers (and other end users) to "rent" >numbers.=20 Well numbering is a National Policy Issue as you well know. :-) ICANN is different. Who gets access to numbering resources and how those resources are allocated is a national policy problem first. That said any protocol development has to try ..try and accommodate those issues consistent with national policy which is often inconsistent from Nation State to Nation State. >Anything-over-HTTP is just invoking a library, so I'm not sure I >understand the trade-off. Or are you suggesting that the new mechanism >needs to be fully backwards-compatible with the current Neustar LNPA and >other APIs? OMG NO its just but the issues of dealing with the legacy systems of BIIRDS the SOA and LSMS in the NPAC is complicated by the issues of Transitioning or at the least revising existing systems. Neustar has been looking at NGN LSMS SOA issues for some time. Again the zombie resistance has been =B3challenging=B2 > >________________________________________ >From: Richard Shockey [richard@shockey.us] >Sent: Wednesday, October 15, 2014 4:34 PM >To: Henning Schulzrinne; modern@ietf.org >Subject: Re: [Modern] Almost Halloween - time to wake the numbering >zombies > >The baggage is dealing with the OSS/BSS systems in carrier voice networks. > EPP as a theory is fine but it would be next to impossible to get a >different transport stack in those systems. Ask a carrier what it takes to >get a change order in one of these products and you will hear endless >tales of woe and rent extraction. > >Frankly EPP was a failure as a IETF protocol since it was not really >designed to be a generic system provisioning protocol. > >Money is the answer what is the question? TM > >Plus I agree JSON vs XML is a second order problem but comes up .. There >are a lot of interesting discussions in the DRINKS archives about this but >there is really no need to go too far back there. >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Thu Oct 16 06:06:21 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830B81A1B59 for ; Thu, 16 Oct 2014 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 iVimhs-UpNDb for ; Thu, 16 Oct 2014 06:06:15 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AB11A1B49 for ; Thu, 16 Oct 2014 06:06:15 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z107so2418312qgd.41 for ; Thu, 16 Oct 2014 06:06:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=JIza7H4BsvmYS3KUmMDHByS1myikBAm3osJb2eb9T7w=; b=YyUnowdQHelU7JplJ3fwCmiw0EZcn8fGUyiDB4k4odx6agfGuoSvSY+CJ6G/6+PLJv yecsQ6lo6Cvht09lvQSU1NFgC4Ll18XDCRRb4EDkmU3bAegM34OAgGv2rQ57Q8GaoNFi 1U1+b8mb4EgwWPXYlwfUuxOredRZDD/GZgF77cIr2i8Lncv/9Dmh+V1qq1KMJ3a7Xwr+ 7pOSQLEuJq6Uc7QYTI+13aO7DtD24pZJXJUVOUI/xyz1boxlNaJG3KMITlgcYrkphL8z AtP5OmDrK/7y8Uf/5y7NoAYjm7Yu5W+e1UJqv4KG9oG3hKwpEAzA3EfBbd1SVXsm96Nw FJgQ== X-Gm-Message-State: ALoCoQk6aUDlHvRYnSzKXuah7QBbsWG3LJewbKIoDhV54kepmuc5XOkDDJkPTB9biI/A8xUWWr7O X-Received: by 10.140.107.11 with SMTP id g11mr1865754qgf.38.1413464774482; Thu, 16 Oct 2014 06:06:14 -0700 (PDT) Received: from [10.33.193.15] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id o98sm3737113qge.39.2014.10.16.06.06.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 06:06:13 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Thu, 16 Oct 2014 09:06:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90B93760-0F63-463F-B8B4-24FEF21967D4@brianrosen.net> References: <4d9eb16a79fa42029f1914bf398de3c4@PLSWE13M08.ad.sprint.com> To: Richard Shockey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Wy0hbiq0UFvcMKWStLqi_1FGYuU Cc: "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:06:18 -0000 I=92m awake and wondering what happened to you all :) REST and json are where it=92s at these days. Now that=92s decided, we = should move on. Also, let=92s keep in mind the difference between a provisioning = protocol and a query protocol. EPP/Drinks was provisioning, ENUM is = query. Different animals. I certainly think that the query has to have more inputs than TN. = Location might be one of the, although we have a location-to-service = mapping solution already. The most important input besides TN is who is = asking, because essentially all the routing mechanisms have different = answers for different queriers. I think we can learn a fair amount from the DRINKS effort on the = provisioning side, but I also think that the world has changed since = that work wrapped up. Brian On Oct 15, 2014, at 4:34 PM, Richard Shockey wrote: >=20 >=20 > The baggage is dealing with the OSS/BSS systems in carrier voice = networks. > EPP as a theory is fine but it would be next to impossible to get a > different transport stack in those systems. Ask a carrier what it = takes to > get a change order in one of these products and you will hear endless > tales of woe and rent extraction. >=20 > Frankly EPP was a failure as a IETF protocol since it was not really > designed to be a generic system provisioning protocol. >=20 > Money is the answer what is the question? TM >=20 > Plus I agree JSON vs XML is a second order problem but comes up .. = There > are a lot of interesting discussions in the DRINKS archives about this = but > there is really no need to go too far back there. >=20 >=20 >=20 >=20 >=20 > On 10/15/14, 3:57 PM, "Henning Schulzrinne" = > wrote: >=20 >> I have no particular emotional attachment to EPP, but in the interest = of >> learning from history, could you be more specific about its = "baggage"? >>=20 >> After all, EPP uses XML and seems simpler than SOAP. (We can have the >> usual JSON-vs-XML debate, but that seems like a second-order issue, = as >> much fun as the binary-vs-text debates that we used to have on IETF >> lists.) >>=20 >> ________________________________________ >> From: Modern [modern-bounces@ietf.org] on behalf of Henning = Schulzrinne >> [Henning.Schulzrinne@fcc.gov] >> Sent: Wednesday, October 15, 2014 3:52 PM >> To: modern@ietf.org >> Subject: Re: [Modern] Almost Halloween - time to wake the numbering >> zombies >>=20 >> There are probably several somewhat separate operations: >>=20 >> * get mapping from number to SIP URL (classical ENUM territory) >> * mapping from number to "whois"-like information >> * managing assignment of numbers to end users and/or carriers, = including >> porting >>=20 >> They may have different needs. I suspect we don't want to cram a = whole >> "whois"-like response into a DNS answer. >>=20 >> I'm less sure how DIAMETER would fit here, assuming we're talking = about a >> AAA-like application, rather than (ab)using DIAMETER as a generic >> query-response protocol. >>=20 >> ________________________________________ >> From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com] >> Sent: Wednesday, October 15, 2014 3:46 PM >> To: Richard Shockey; Henning Schulzrinne; modern@ietf.org >> Subject: RE: [Modern] Almost Halloween - time to wake the numbering >> zombies >>=20 >> I'm awake! I'm awake! >>=20 >> Richard and Henning, >>=20 >> Has anyone discussed moving beyond DNS/ENUM? I=92m wondering if = something >> based on DIAMETER and XML might be a better long-term choice for = routing >> information management requirements. If you're familiar with work in >> this area (and I suspect there is), I'd be interested in looking at = it. >>=20 >> Best regards, >>=20 >>=20 >> Pierce Gorman >> Voice Architecture >> Core Planning/Sprint >> 913-439-4368 (Desk) >>=20 >>=20 >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard = Shockey >> Sent: October 15, 2014 2:22 PM >> To: Henning Schulzrinne; modern@ietf.org >> Subject: Re: [Modern] Almost Halloween - time to wake the numbering >> zombies >>=20 >>=20 >> Well I=B9m delighted you brought up the subject. I could make up = some >> really bad jokes about certain numbering committees .. >>=20 >> During the FCC workshop I mentioned that years ago we had some = consensus >> that EPP was not appropriate for the provisioning portion of the = protocol >> problem statement. >>=20 >> We set up IETF DRINKS in 08 specifically to look at the provisioning >> problem. EPP was set up for the sole purpose of serving the domain = name >> industry, dealing with the ICANN requirements and as such was way = carried >> a lot of baggage with it. >>=20 >> In addition the carriers I spoke to were adamant they did not want = any >> new protocol stack in their already insanely expensive OSS/BSS = systems >> and they were all moving to something like HTTP SOAP or some RESTFUL = like >> protocols XML or JSON defined schema=B9s. >>=20 >> I=B9m pretty sure that sentiment has not changed. DRINKS as a WG was = a >> failure for several reasons, principally timing. I really don=B9t = think the >> industry was ready to revisit the numbering provisioning problem with = a >> clean sheet of paper. >>=20 >> Times change=8A attitudes change. I can assure you that the SIP = Forum ATIS >> NNI workshop did in fact discuss what NGN numbering would look like = in >> the post Transition phase and everyone is going to see the work in >> progress documents in a day or so. I=B9ll be posting a URL to the = usual RAI >> lists. So again Henning your timing is excellent. >>=20 >> =8B >> 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 >>=20 >>=20 >>=20 >> On 10/15/14, 2:50 PM, "Henning Schulzrinne" = >> wrote: >>=20 >>> We set up this list after the FCC numbering workshop earlier this = year to >>> see if there's interest and an initial list of to-do's in = modernizing >>> E.164 numbering delegation, porting, and lookup. I'd like to = re-awaken >>> this effort and see if we can make some initial progress. >>>=20 >>> I see two fundamental technical discussions: >>>=20 >>> (1) Architecture for managing numbers, along the >>> centralized-to-distributed spectrum >>>=20 >>> (2) What protocol pieces are out there that can be re-used (WEIRDS? >>> EPP?), are they relevant and which ones are still needed? >>>=20 >>> Henning >>>=20 >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://www.ietf.org/mailman/listinfo/modern >>=20 >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >> ________________________________ >>=20 >> This e-mail may contain Sprint proprietary information intended for = the >> sole use of the recipient(s). Any use by others is prohibited. If you = are >> not the intended recipient, please contact the sender and delete all >> copies of the message. >>=20 >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Oct 16 09:45:52 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FE41A00FE for ; Thu, 16 Oct 2014 09:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 cmTlCRAd033O for ; Thu, 16 Oct 2014 09:45:46 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 918841A0105 for ; Thu, 16 Oct 2014 09:45:45 -0700 (PDT) Received: from pps.filterd (m0049367.ppops.net [127.0.0.1]) by m0049367.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s9GGe87f017545 for ; Thu, 16 Oct 2014 12:45:44 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049367.ppops.net-0018ba01. with ESMTP id 1q2cbd8kef-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Oct 2014 12:45:43 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 12:45:43 -0400 From: "McGarry, Tom" To: "modern@ietf.org" Thread-Topic: [Modern] Almost Halloween - time to wake the numbering zombies Thread-Index: AQHP6K1SfwMszEY/bkWccbETfTCI7Zwx00SAgAABlYCAAAE4gIAACpgAgAEU8wD///pEgA== Date: Thu, 16 Oct 2014 16:45:43 +0000 Message-ID: In-Reply-To: <90B93760-0F63-463F-B8B4-24FEF21967D4@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.205.44] Content-Type: text/plain; charset="utf-8" Content-ID: <0EB8E4307BEB09489C93F14F82C41C04@neustar.biz> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7593 signatures=670553 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410160154 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/uXhMBDPWuPK2riVFH7InMSoOiz8 Subject: Re: [Modern] Almost Halloween - time to wake the numbering zombies X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:45:49 -0000 SW4gYWRkaXRpb24gdG8gcHJvdmlzaW9uaW5nIChnZXR0aW5nIGluZm9ybWF0aW9uIHRvIGFuIGFk bWluaXN0cmF0b3IpIGFuZA0KcXVlcnlpbmcgKGdldHRpbmcgc21hbGwgYW1vdW50cyBvZiBkYXRh IGZyb20gYW4gYWRtaW5pc3RyYXRvciksIHdlIHNob3VsZA0KYWxzbyBjb25zaWRlciBkYXRhIGRp c3RyaWJ1dGlvbiAoc2VuZGluZyBsYXJnZSBhbW91bnRzIG9mIGRhdGEgcGx1cw0KcmVndWxhciB1 cGRhdGVzOyBpLmUuLCBhZGRyZXNzaW5nIGRhdGE7IGZyb20gYW4gYWRtaW5pc3RyYXRvciB0byBt YW55KS4NCklkZWFsbHkganVzdCBhYm91dCBhbnkgZW50aXR5IHNob3VsZCBiZSBhYmxlIHRvIGdl dCBhbiB1cGRhdGVkIGNvbXBsZXRlDQpjb3B5IG9mIGFuIGFkZHJlc3NpbmcgREIuDQoNCk9uIDEw LzE2LzE0IDk6MDYgQU0sICJCcmlhbiBSb3NlbiIgPGJyQGJyaWFucm9zZW4ubmV0PiB3cm90ZToN Cg0KPjxodG1sPg0KPknigJltIGF3YWtlIGFuZCB3b25kZXJpbmcgd2hhdCBoYXBwZW5lZCB0byB5 b3UgYWxsIDopDQo+DQo+UkVTVCBhbmQganNvbiBhcmUgd2hlcmUgaXTigJlzIGF0IHRoZXNlIGRh eXMuICBOb3cgdGhhdOKAmXMgZGVjaWRlZCwgd2UNCj5zaG91bGQgbW92ZSBvbi4NCj4NCj5BbHNv LCBsZXTigJlzIGtlZXAgaW4gbWluZCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcHJvdmlzaW9u aW5nIHByb3RvY29sDQo+YW5kIGEgcXVlcnkgcHJvdG9jb2wuICBFUFAvRHJpbmtzIHdhcyBwcm92 aXNpb25pbmcsIEVOVU0gaXMgcXVlcnkuDQo+RGlmZmVyZW50IGFuaW1hbHMuDQo+DQo+SSBjZXJ0 YWlubHkgdGhpbmsgdGhhdCB0aGUgcXVlcnkgaGFzIHRvIGhhdmUgbW9yZSBpbnB1dHMgdGhhbiBU Ti4NCj5Mb2NhdGlvbiBtaWdodCBiZSBvbmUgb2YgdGhlLCBhbHRob3VnaCB3ZSBoYXZlIGEgbG9j YXRpb24tdG8tc2VydmljZQ0KPm1hcHBpbmcgc29sdXRpb24gYWxyZWFkeS4gIFRoZSBtb3N0IGlt cG9ydGFudCBpbnB1dCBiZXNpZGVzIFROIGlzIHdobyBpcw0KPmFza2luZywgYmVjYXVzZSBlc3Nl bnRpYWxseSBhbGwgdGhlIHJvdXRpbmcgbWVjaGFuaXNtcyBoYXZlIGRpZmZlcmVudA0KPmFuc3dl cnMgZm9yIGRpZmZlcmVudCBxdWVyaWVycy4NCj4NCj5JIHRoaW5rIHdlIGNhbiBsZWFybiBhIGZh aXIgYW1vdW50IGZyb20gdGhlIERSSU5LUyBlZmZvcnQgb24gdGhlDQo+cHJvdmlzaW9uaW5nIHNp ZGUsIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCB0aGUgd29ybGQgaGFzIGNoYW5nZWQgc2luY2UgdGhh dA0KPndvcmsgd3JhcHBlZCB1cC4NCj4NCj5Ccmlhbg0KPk9uIE9jdCAxNSwgMjAxNCwgYXQgNDoz NCBQTSwgUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNob2NrZXkudXM+IHdyb3RlOg0KPg0KPj4g DQo+PiANCj4+IFRoZSBiYWdnYWdlIGlzIGRlYWxpbmcgd2l0aCB0aGUgT1NTL0JTUyBzeXN0ZW1z IGluIGNhcnJpZXIgdm9pY2UNCj4+bmV0d29ya3MuDQo+PiBFUFAgYXMgYSB0aGVvcnkgaXMgZmlu ZSBidXQgaXQgd291bGQgYmUgbmV4dCB0byBpbXBvc3NpYmxlIHRvIGdldCBhDQo+PiBkaWZmZXJl bnQgdHJhbnNwb3J0IHN0YWNrIGluIHRob3NlIHN5c3RlbXMuIEFzayBhIGNhcnJpZXIgd2hhdCBp dCB0YWtlcw0KPj50bw0KPj4gZ2V0IGEgY2hhbmdlIG9yZGVyIGluIG9uZSBvZiB0aGVzZSBwcm9k dWN0cyBhbmQgeW91IHdpbGwgaGVhciBlbmRsZXNzDQo+PiB0YWxlcyBvZiB3b2UgYW5kIHJlbnQg ZXh0cmFjdGlvbi4NCj4+IA0KPj4gRnJhbmtseSBFUFAgd2FzIGEgZmFpbHVyZSBhcyBhIElFVEYg cHJvdG9jb2wgc2luY2UgaXQgd2FzIG5vdCByZWFsbHkNCj4+IGRlc2lnbmVkIHRvIGJlIGEgZ2Vu ZXJpYyBzeXN0ZW0gcHJvdmlzaW9uaW5nIHByb3RvY29sLg0KPj4gDQo+PiBNb25leSBpcyB0aGUg YW5zd2VyIHdoYXQgaXMgdGhlIHF1ZXN0aW9uPyBUTQ0KPj4gDQo+PiBQbHVzIEkgYWdyZWUgSlNP TiB2cyBYTUwgaXMgYSBzZWNvbmQgb3JkZXIgcHJvYmxlbSBidXQgY29tZXMgdXAgLi4gVGhlcmUN Cj4+IGFyZSBhIGxvdCBvZiBpbnRlcmVzdGluZyBkaXNjdXNzaW9ucyBpbiB0aGUgRFJJTktTIGFy Y2hpdmVzIGFib3V0IHRoaXMNCj4+YnV0DQo+PiB0aGVyZSBpcyByZWFsbHkgbm8gbmVlZCB0byBn byB0b28gZmFyIGJhY2sgdGhlcmUuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gMTAv MTUvMTQsIDM6NTcgUE0sICJIZW5uaW5nIFNjaHVsenJpbm5lIg0KPj48SGVubmluZy5TY2h1bHpy aW5uZUBmY2MuZ292Pg0KPj4gd3JvdGU6DQo+PiANCj4+PiBJIGhhdmUgbm8gcGFydGljdWxhciBl bW90aW9uYWwgYXR0YWNobWVudCB0byBFUFAsIGJ1dCBpbiB0aGUgaW50ZXJlc3QNCj4+Pm9mDQo+ Pj4gbGVhcm5pbmcgZnJvbSBoaXN0b3J5LCBjb3VsZCB5b3UgYmUgbW9yZSBzcGVjaWZpYyBhYm91 dCBpdHMgImJhZ2dhZ2UiPw0KPj4+IA0KPj4+IEFmdGVyIGFsbCwgRVBQIHVzZXMgWE1MIGFuZCBz ZWVtcyBzaW1wbGVyIHRoYW4gU09BUC4gKFdlIGNhbiBoYXZlIHRoZQ0KPj4+IHVzdWFsIEpTT04t dnMtWE1MIGRlYmF0ZSwgYnV0IHRoYXQgc2VlbXMgbGlrZSBhIHNlY29uZC1vcmRlciBpc3N1ZSwg YXMNCj4+PiBtdWNoIGZ1biBhcyB0aGUgYmluYXJ5LXZzLXRleHQgZGViYXRlcyB0aGF0IHdlIHVz ZWQgdG8gaGF2ZSBvbiBJRVRGDQo+Pj4gbGlzdHMuKQ0KPj4+IA0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBGcm9tOiBNb2Rlcm4gW21vZGVybi1ib3Vu Y2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YgSGVubmluZyBTY2h1bHpyaW5uZQ0KPj4+IFtIZW5u aW5nLlNjaHVsenJpbm5lQGZjYy5nb3ZdDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE1 LCAyMDE0IDM6NTIgUE0NCj4+PiBUbzogbW9kZXJuQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6 IFtNb2Rlcm5dIEFsbW9zdCBIYWxsb3dlZW4gLSB0aW1lIHRvIHdha2UgdGhlIG51bWJlcmluZw0K Pj4+IHpvbWJpZXMNCj4+PiANCj4+PiBUaGVyZSBhcmUgcHJvYmFibHkgc2V2ZXJhbCBzb21ld2hh dCBzZXBhcmF0ZSBvcGVyYXRpb25zOg0KPj4+IA0KPj4+ICogZ2V0IG1hcHBpbmcgZnJvbSBudW1i ZXIgdG8gU0lQIFVSTCAoY2xhc3NpY2FsIEVOVU0gdGVycml0b3J5KQ0KPj4+ICogbWFwcGluZyBm cm9tIG51bWJlciB0byAid2hvaXMiLWxpa2UgaW5mb3JtYXRpb24NCj4+PiAqIG1hbmFnaW5nIGFz c2lnbm1lbnQgb2YgbnVtYmVycyB0byBlbmQgdXNlcnMgYW5kL29yIGNhcnJpZXJzLA0KPj4+aW5j bHVkaW5nDQo+Pj4gcG9ydGluZw0KPj4+IA0KPj4+IFRoZXkgbWF5IGhhdmUgZGlmZmVyZW50IG5l ZWRzLiBJIHN1c3BlY3Qgd2UgZG9uJ3Qgd2FudCB0byBjcmFtIGEgd2hvbGUNCj4+PiAid2hvaXMi LWxpa2UgcmVzcG9uc2UgaW50byBhIEROUyBhbnN3ZXIuDQo+Pj4gDQo+Pj4gSSdtIGxlc3Mgc3Vy ZSBob3cgRElBTUVURVIgd291bGQgZml0IGhlcmUsIGFzc3VtaW5nIHdlJ3JlIHRhbGtpbmcNCj4+ PmFib3V0IGENCj4+PiBBQUEtbGlrZSBhcHBsaWNhdGlvbiwgcmF0aGVyIHRoYW4gKGFiKXVzaW5n IERJQU1FVEVSIGFzIGEgZ2VuZXJpYw0KPj4+IHF1ZXJ5LXJlc3BvbnNlIHByb3RvY29sLg0KPj4+ IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBGcm9t OiBHb3JtYW4sIFBpZXJjZSBBIFtOVEtdIFtQaWVyY2UuR29ybWFuQHNwcmludC5jb21dDQo+Pj4g U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE1LCAyMDE0IDM6NDYgUE0NCj4+PiBUbzogUmljaGFy ZCBTaG9ja2V5OyBIZW5uaW5nIFNjaHVsenJpbm5lOyBtb2Rlcm5AaWV0Zi5vcmcNCj4+PiBTdWJq ZWN0OiBSRTogW01vZGVybl0gQWxtb3N0IEhhbGxvd2VlbiAtIHRpbWUgdG8gd2FrZSB0aGUgbnVt YmVyaW5nDQo+Pj4gem9tYmllcw0KPj4+IA0KPj4+IEknbSBhd2FrZSEgIEknbSBhd2FrZSENCj4+ PiANCj4+PiBSaWNoYXJkIGFuZCBIZW5uaW5nLA0KPj4+IA0KPj4+IEhhcyBhbnlvbmUgZGlzY3Vz c2VkIG1vdmluZyBiZXlvbmQgRE5TL0VOVU0/ICBJ4oCZbSB3b25kZXJpbmcgaWYNCj4+PnNvbWV0 aGluZw0KPj4+IGJhc2VkIG9uIERJQU1FVEVSIGFuZCBYTUwgbWlnaHQgYmUgYSBiZXR0ZXIgbG9u Zy10ZXJtIGNob2ljZSBmb3INCj4+PnJvdXRpbmcNCj4+PiBpbmZvcm1hdGlvbiBtYW5hZ2VtZW50 IHJlcXVpcmVtZW50cy4gIElmIHlvdSdyZSBmYW1pbGlhciB3aXRoIHdvcmsgaW4NCj4+PiB0aGlz IGFyZWEgKGFuZCBJIHN1c3BlY3QgdGhlcmUgaXMpLCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBsb29r aW5nIGF0IGl0Lg0KPj4+IA0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiANCj4+PiANCj4+PiBQaWVy Y2UgR29ybWFuDQo+Pj4gVm9pY2UgQXJjaGl0ZWN0dXJlDQo+Pj4gQ29yZSBQbGFubmluZy9TcHJp bnQNCj4+PiA5MTMtNDM5LTQzNjggKERlc2spDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQNCj4+PlNob2NrZXkNCj4+PiBTZW50OiBPY3Rv YmVyIDE1LCAyMDE0IDI6MjIgUE0NCj4+PiBUbzogSGVubmluZyBTY2h1bHpyaW5uZTsgbW9kZXJu QGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtNb2Rlcm5dIEFsbW9zdCBIYWxsb3dlZW4gLSB0 aW1lIHRvIHdha2UgdGhlIG51bWJlcmluZw0KPj4+IHpvbWJpZXMNCj4+PiANCj4+PiANCj4+PiBX ZWxsIEnCuW0gZGVsaWdodGVkIHlvdSBicm91Z2h0IHVwIHRoZSBzdWJqZWN0LiAgSSBjb3VsZCBt YWtlIHVwIHNvbWUNCj4+PiByZWFsbHkgYmFkIGpva2VzIGFib3V0IGNlcnRhaW4gbnVtYmVyaW5n IGNvbW1pdHRlZXMgLi4NCj4+PiANCj4+PiBEdXJpbmcgdGhlIEZDQyB3b3Jrc2hvcCBJIG1lbnRp b25lZCB0aGF0IHllYXJzIGFnbyB3ZSBoYWQgc29tZQ0KPj4+Y29uc2Vuc3VzDQo+Pj4gdGhhdCBF UFAgd2FzIG5vdCBhcHByb3ByaWF0ZSBmb3IgdGhlIHByb3Zpc2lvbmluZyBwb3J0aW9uIG9mIHRo ZQ0KPj4+cHJvdG9jb2wNCj4+PiBwcm9ibGVtIHN0YXRlbWVudC4NCj4+PiANCj4+PiBXZSBzZXQg dXAgSUVURiBEUklOS1MgaW4gMDggc3BlY2lmaWNhbGx5IHRvIGxvb2sgYXQgdGhlIHByb3Zpc2lv bmluZw0KPj4+IHByb2JsZW0uIEVQUCB3YXMgc2V0IHVwIGZvciB0aGUgc29sZSBwdXJwb3NlIG9m IHNlcnZpbmcgdGhlIGRvbWFpbiBuYW1lDQo+Pj4gaW5kdXN0cnksIGRlYWxpbmcgd2l0aCB0aGUg SUNBTk4gcmVxdWlyZW1lbnRzIGFuZCBhcyBzdWNoIHdhcyB3YXkNCj4+PmNhcnJpZWQNCj4+PiBh IGxvdCBvZiBiYWdnYWdlIHdpdGggaXQuDQo+Pj4gDQo+Pj4gSW4gYWRkaXRpb24gdGhlIGNhcnJp ZXJzIEkgc3Bva2UgdG8gd2VyZSBhZGFtYW50IHRoZXkgZGlkIG5vdCB3YW50IGFueQ0KPj4+IG5l dyBwcm90b2NvbCBzdGFjayBpbiB0aGVpciBhbHJlYWR5IGluc2FuZWx5IGV4cGVuc2l2ZSBPU1Mv QlNTIHN5c3RlbXMNCj4+PiBhbmQgdGhleSB3ZXJlIGFsbCBtb3ZpbmcgdG8gc29tZXRoaW5nIGxp a2UgSFRUUCBTT0FQIG9yIHNvbWUgUkVTVEZVTA0KPj4+bGlrZQ0KPj4+IHByb3RvY29scyBYTUwg b3IgSlNPTiBkZWZpbmVkIHNjaGVtYcK5cy4NCj4+PiANCj4+PiBJwrltIHByZXR0eSBzdXJlIHRo YXQgc2VudGltZW50IGhhcyBub3QgY2hhbmdlZC4gIERSSU5LUyBhcyBhIFdHIHdhcyBhDQo+Pj4g ZmFpbHVyZSBmb3Igc2V2ZXJhbCByZWFzb25zLCBwcmluY2lwYWxseSB0aW1pbmcuIEkgcmVhbGx5 IGRvbsK5dCB0aGluaw0KPj4+dGhlDQo+Pj4gaW5kdXN0cnkgd2FzIHJlYWR5IHRvIHJldmlzaXQg dGhlIG51bWJlcmluZyBwcm92aXNpb25pbmcgcHJvYmxlbSB3aXRoIGENCj4+PiBjbGVhbiBzaGVl dCBvZiBwYXBlci4NCj4+PiANCj4+PiBUaW1lcyBjaGFuZ2XFoCBhdHRpdHVkZXMgY2hhbmdlLiAg SSBjYW4gYXNzdXJlIHlvdSB0aGF0IHRoZSBTSVAgRm9ydW0NCj4+PkFUSVMNCj4+PiBOTkkgd29y a3Nob3AgZGlkIGluIGZhY3QgZGlzY3VzcyB3aGF0IE5HTiBudW1iZXJpbmcgd291bGQgbG9vayBs aWtlIGluDQo+Pj4gdGhlIHBvc3QgVHJhbnNpdGlvbiBwaGFzZSBhbmQgZXZlcnlvbmUgaXMgZ29p bmcgdG8gc2VlIHRoZSB3b3JrIGluDQo+Pj4gcHJvZ3Jlc3MgZG9jdW1lbnRzIGluIGEgZGF5IG9y IHNvLiBJwrlsbCBiZSBwb3N0aW5nIGEgVVJMIHRvIHRoZSB1c3VhbA0KPj4+UkFJDQo+Pj4gbGlz dHMuIFNvIGFnYWluIEhlbm5pbmcgeW91ciB0aW1pbmcgaXMgZXhjZWxsZW50Lg0KPj4+IA0KPj4+ IOKAuQ0KPj4+IFJpY2hhcmQgU2hvY2tleQ0KPj4+IFNob2NrZXkgQ29uc3VsdGluZyBMTEMNCj4+ PiBDaGFpcm1hbiBvZiB0aGUgQm9hcmQgU0lQIEZvcnVtDQo+Pj4gd3d3LnNob2NrZXkudXMNCj4+ PiBXd3cuc2lwZm9ydW0ub3JnDQo+Pj4gcmljaGFyZDxhdD5zaG9ja2V5LnVzDQo+Pj4gU2t5cGUt TGlua2VkaW4tRmFjZWJvb2sgcnNob2NrZXkxMDENCj4+PiBQU1ROICsxIDcwMy01OTMtMjY4Mw0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDEwLzE1LzE0LCAyOjUwIFBNLCAi SGVubmluZyBTY2h1bHpyaW5uZSINCj4+PjxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+DQo+ Pj4gd3JvdGU6DQo+Pj4gDQo+Pj4+IFdlIHNldCB1cCB0aGlzIGxpc3QgYWZ0ZXIgdGhlIEZDQyBu dW1iZXJpbmcgd29ya3Nob3AgZWFybGllciB0aGlzDQo+Pj4+eWVhciB0bw0KPj4+PiBzZWUgaWYg dGhlcmUncyBpbnRlcmVzdCBhbmQgYW4gaW5pdGlhbCBsaXN0IG9mIHRvLWRvJ3MgaW4gbW9kZXJu aXppbmcNCj4+Pj4gRS4xNjQgbnVtYmVyaW5nIGRlbGVnYXRpb24sIHBvcnRpbmcsIGFuZCBsb29r dXAuIEknZCBsaWtlIHRvIHJlLWF3YWtlbg0KPj4+PiB0aGlzIGVmZm9ydCBhbmQgc2VlIGlmIHdl IGNhbiBtYWtlIHNvbWUgaW5pdGlhbCBwcm9ncmVzcy4NCj4+Pj4gDQo+Pj4+IEkgc2VlIHR3byBm dW5kYW1lbnRhbCB0ZWNobmljYWwgZGlzY3Vzc2lvbnM6DQo+Pj4+IA0KPj4+PiAoMSkgQXJjaGl0 ZWN0dXJlIGZvciBtYW5hZ2luZyBudW1iZXJzLCBhbG9uZyB0aGUNCj4+Pj4gY2VudHJhbGl6ZWQt dG8tZGlzdHJpYnV0ZWQgc3BlY3RydW0NCj4+Pj4gDQo+Pj4+ICgyKSBXaGF0IHByb3RvY29sIHBp ZWNlcyBhcmUgb3V0IHRoZXJlIHRoYXQgY2FuIGJlIHJlLXVzZWQgKFdFSVJEUz8NCj4+Pj4gRVBQ PyksIGFyZSB0aGV5IHJlbGV2YW50IGFuZCB3aGljaCBvbmVzIGFyZSBzdGlsbCBuZWVkZWQ/DQo+ Pj4+IA0KPj4+PiBIZW5uaW5nDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+Pj4+IE1v ZGVybkBpZXRmLm9yZw0KPj4+PiANCj4+Pj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbQ0KPj4+PmFuX2xpc3RpbmZv X21vZGVybiZkPUFBSUYtZyZjPU1PcHRObFZ0SUVUZURBTENfbFVMcncmcj00S2xtMzJpQjdIdWZ2 ZWVJDQo+Pj4+RGNMZXh0WjFvb05jZnAwMUlZSWFWcXNPUmpJJm09QW0tYXVEcndrX3VYNHJYRmUt WXppSzQ1WnBxVFk1OFMwaEx5MlZPWmMNCj4+Pj5oSSZzPTZsNUt6dGtjcEVEelhQT094U0NVTmJs ajlsUjZKNmJUczdtUW0xb3lQSTgmZT0NCj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE1vZGVybiBtYWlsaW5nIGxpc3QN Cj4+PiBNb2Rlcm5AaWV0Zi5vcmcNCj4+PiANCj4+Pmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYQ0KPj4+bl9saXN0 aW5mb19tb2Rlcm4mZD1BQUlGLWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JnI9NEtsbTMyaUI3 SHVmdmVlSURjDQo+Pj5MZXh0WjFvb05jZnAwMUlZSWFWcXNPUmpJJm09QW0tYXVEcndrX3VYNHJY RmUtWXppSzQ1WnBxVFk1OFMwaEx5MlZPWmNoSSYNCj4+PnM9Nmw1S3p0a2NwRUR6WFBPT3hTQ1VO YmxqOWxSNko2YlRzN21RbTFveVBJOCZlPQ0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4gDQo+Pj4gVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUNCj4+PiBzb2xlIHVzZSBvZiB0 aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UN Cj4+PmFyZQ0KPj4+IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsDQo+Pj4gY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KPj4+ IA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gTW9kZXJuIG1haWxpbmcgbGlzdA0KPj4+IE1vZGVybkBpZXRmLm9yZw0KPj4+IA0K Pj4+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hDQo+Pj5uX2xpc3RpbmZvX21vZGVybiZkPUFBSUYtZyZjPU1PcHRO bFZ0SUVUZURBTENfbFVMcncmcj00S2xtMzJpQjdIdWZ2ZWVJRGMNCj4+PkxleHRaMW9vTmNmcDAx SVlJYVZxc09SakkmbT1BbS1hdURyd2tfdVg0clhGZS1ZemlLNDVacHFUWTU4UzBoTHkyVk9aY2hJ Jg0KPj4+cz02bDVLenRrY3BFRHpYUE9PeFNDVU5ibGo5bFI2SjZiVHM3bVFtMW95UEk4JmU9DQo+ Pj4gDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+PiBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+Pj4gTW9kZXJuQGlldGYub3JnDQo+Pj4g DQo+Pj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWENCj4+Pm5fbGlzdGluZm9fbW9kZXJuJmQ9QUFJRi1nJmM9TU9w dE5sVnRJRVRlREFMQ19sVUxydyZyPTRLbG0zMmlCN0h1ZnZlZUlEYw0KPj4+TGV4dFoxb29OY2Zw MDFJWUlhVnFzT1JqSSZtPUFtLWF1RHJ3a191WDRyWEZlLVl6aUs0NVpwcVRZNThTMGhMeTJWT1pj aEkmDQo+Pj5zPTZsNUt6dGtjcEVEelhQT094U0NVTmJsajlsUjZKNmJUczdtUW0xb3lQSTgmZT0N Cj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gTW9kZXJuIG1haWxpbmcgbGlzdA0KPj4gTW9kZXJuQGlldGYub3JnDQo+PiANCj4+ aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbg0KPj5fbGlzdGluZm9fbW9kZXJuJmQ9QUFJRi1nJmM9TU9wdE5sVnRJ RVRlREFMQ19sVUxydyZyPTRLbG0zMmlCN0h1ZnZlZUlEY0xlDQo+Pnh0WjFvb05jZnAwMUlZSWFW cXNPUmpJJm09QW0tYXVEcndrX3VYNHJYRmUtWXppSzQ1WnBxVFk1OFMwaEx5MlZPWmNoSSZzPTYN Cj4+bDVLenRrY3BFRHpYUE9PeFNDVU5ibGo5bFI2SjZiVHM3bVFtMW95UEk4JmU9DQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Nb2Rlcm4gbWFp bGluZyBsaXN0DQo+TW9kZXJuQGlldGYub3JnDQo+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl8NCj5saXN0aW5m b19tb2Rlcm4mZD1BQUlGLWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JnI9NEtsbTMyaUI3SHVm dmVlSURjTGV4dA0KPloxb29OY2ZwMDFJWUlhVnFzT1JqSSZtPUFtLWF1RHJ3a191WDRyWEZlLVl6 aUs0NVpwcVRZNThTMGhMeTJWT1pjaEkmcz02bDVLDQo+enRrY3BFRHpYUE9PeFNDVU5ibGo5bFI2 SjZiVHM3bVFtMW95UEk4JmU9IA0KDQo= From nobody Thu Oct 16 12:06:52 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADECB1A870D for ; Thu, 16 Oct 2014 12:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZpPkvB1ot5sG for ; Thu, 16 Oct 2014 12:06:47 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44781A1A7D for ; Thu, 16 Oct 2014 12:06:47 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 64710445.0.6126882.00-2030.17273402.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 16 Oct 2014 19:06:47 +0000 (UTC) X-MXL-Hash: 5440174711cbb21c-50492e5027e3229b1d0890d376582ffc400fc8ef 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 s9GJ6kxF018395 for ; Thu, 16 Oct 2014 15:06:46 -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 s9GJ6dfK018278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Oct 2014 15:06:43 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Thu, 16 Oct 2014 19:06:24 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 15:06:23 -0400 From: "PFAUTZ, PENN L" To: "modern@ietf.org" Thread-Topic: [Modern] Zombie numbering issues Thread-Index: AQHP6L/ILNUG0QEXpUWV4L2Bl7PO+pwzEaLw Date: Thu, 16 Oct 2014 19:06:23 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] 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-AnalysisOut: [v=2.0 cv=ae/Wa2Ut c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=hna1Re9ts] X-AnalysisOut: [7mlvvy3SW4A:9 a=CjuIK1q_8ugA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/qnRyeMQva8g4ODnJAamaneMH2Wg Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:06:50 -0000 As much as it's fun to discuss what protocols we have in the closet that m= ight be useful or not, am I wrong for thinking we need to start with some a= ssumptions about the architecture and what it has to do? I agree that that number administration regime is a national matter but per= haps we can still devise a generic framework that will be attractive to rig= ht-thinking regulators everywhere :-) So, Based on the Workshop back in March can we assume that there will be a numb= ering registry that combines resource allocation and porting (delegation) f= or all types of E.164 numbers? This is not saying whether the registry is c= entralized or distributed a la Whitespaces. So we'll need some kind of regi= strar-registry protocol. What are the necessary characteristics? Can we ass= ume anything about the actors? Can we also assume that the registry is the apex for distribution of routin= g formation? I say apex because one decision is whether the registry contai= ns such information (and potentially service logic to derive it) itself or = delegates that and potentially other, e.g., identity related information to= other parties. Depending on the answer, different protocols may be appropr= iate. If there is delegation there might be different protocols involved at diffe= rent stages of the resolution to the desired information. Penn Pfautz From nobody Thu Oct 16 12:17:19 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09401A8830 for ; Thu, 16 Oct 2014 12:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o4gU1Fw5T50J for ; Thu, 16 Oct 2014 12:17:16 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id A2CDA1A880E for ; Thu, 16 Oct 2014 12:17:14 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "PFAUTZ, PENN L" , "modern@ietf.org" Thread-Topic: [Modern] Zombie numbering issues Thread-Index: AQHP6L+/k7zYAM8LFEGMVjP9RQxsP5wzWhyA//+95eQ= Date: Thu, 16 Oct 2014 19:16:52 +0000 References: , <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Y6AYW0F7VSEqC_PWmB8NTBPztxA Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:17:19 -0000 My hope is that similar protocols would work, maybe as subsets or with addi= tions, for both the hierarchical and "flat" case. It is at least possible t= hat we'll see combinations, e.g., flat at the top and trees below, or a tre= e with some flat parts in a branch (e.g., between replicas or between parts= of an organization).=0A= =0A= I'm implicitly assuming that the actors are cooperative, i.e., they authent= icate themselves, and they don't intentionally try to inflict damage.=0A= =0A= For routing, I wonder whether we'll see both: some entries will contain an = initial routing contact (a SIP URL, some ENUM root, etc.), others may not. = Would it be sufficient to provide this as optional data, recognizing that i= t may not be always present?=0A= =0A= Is it sufficient to have one query protocol for everyone, where the informa= tion that is returned depends on who is asking? (For example, the assignee = of a number gets lots of information, an anonymous querier may only get the= rough equivalent of DNS whois, i.e., contact information for the assignee.= )=0A= =0A= Since policies and business arrangements are still evolving, I'm trying to = explore flexible options, so that we don't end up in embedding too many ass= umptions, as, to some extent, ENUM did, where the assumption seems to have = been that of a single kind of querier.=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of PFAUTZ, PENN L [pp3129@= att.com]=0A= Sent: Thursday, October 16, 2014 3:06 PM=0A= To: modern@ietf.org=0A= Subject: Re: [Modern] Zombie numbering issues=0A= =0A= As much as it's fun to discuss what protocols we have in the closet that m= ight be useful or not, am I wrong for thinking we need to start with some a= ssumptions about the architecture and what it has to do?=0A= =0A= I agree that that number administration regime is a national matter but per= haps we can still devise a generic framework that will be attractive to rig= ht-thinking regulators everywhere :-)=0A= So,=0A= Based on the Workshop back in March can we assume that there will be a numb= ering registry that combines resource allocation and porting (delegation) f= or all types of E.164 numbers? This is not saying whether the registry is c= entralized or distributed a la Whitespaces. So we'll need some kind of regi= strar-registry protocol. What are the necessary characteristics? Can we ass= ume anything about the actors?=0A= =0A= Can we also assume that the registry is the apex for distribution of routin= g formation? I say apex because one decision is whether the registry contai= ns such information (and potentially service logic to derive it) itself or = delegates that and potentially other, e.g., identity related information to= other parties. Depending on the answer, different protocols may be appropr= iate.=0A= If there is delegation there might be different protocols involved at diffe= rent stages of the resolution to the desired information.=0A= =0A= Penn Pfautz=0A= =0A= =0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= From nobody Thu Oct 16 12:29:22 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717601A887C for ; Thu, 16 Oct 2014 12:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 jDtGOCItrVFS for ; Thu, 16 Oct 2014 12:29:18 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB57C1A8876 for ; Thu, 16 Oct 2014 12:29:17 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id n8so2910640qaq.28 for ; Thu, 16 Oct 2014 12:29:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NeEEjLpaFj91XHrLtpSCUL6m0js7rgbbNFOuyC1tksc=; b=D1JRHrSfN4lEl6RvWo+i+KAxCpfwUgoVGL2SqDKTWm4CjNKROsartI7KRrF5001RNI SR8ZiUPb6knApfI+IVCR8+VbzyEy1Th8HhbAFwGKT2nYIYo28kGkFYkWhfeHqt1TPLim z3fARAhcKYEv1Lo/gBTrmzu4bWL97IWrXBk27tCQmbNDacAS22i/occVgCyZHFKbJOBT M0OjN1vB/dh9fskPXTFIPzB6Pw11+rlduS1jCEmKPVridaR9V2tfuGwZpkYM68wACLUs kqeoOsBeAE3pI76IsCzCVAsRFhomUNpq9muSEUnOrHXt9OAjvm7YHUSxOo41H3TypMD0 KX/A== X-Gm-Message-State: ALoCoQmgko3wJAue89+soWy6wrKYnbELnpO+1ISi7fpr9kF+YKi32K/COjVFQbwVWaqStN/eWS1F X-Received: by 10.224.50.196 with SMTP id a4mr5486276qag.88.1413487756456; Thu, 16 Oct 2014 12:29:16 -0700 (PDT) Received: from [10.33.193.15] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id d2sm14598921qab.24.2014.10.16.12.29.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 12:29:15 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Thu, 16 Oct 2014 15:29:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02A77C15-0CE8-47E3-A4B2-D74BC08E135C@brianrosen.net> References: , <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/ygHPeIcH_ua2ShSCjQvORL4FgyQ Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:29:20 -0000 I definitely think it=92s an open architectural question of whether = there is one database that has =93ownership=94 information, and another = that has routing. In some cases, of course, knowledge of ownership is = enough information to complete routing, so that argues there is one = database. But we should seriously consider if that is what we want. I do think that we want to take into consideration that we=92re clearly = headed towards two complications we don=92t consider today: 1. More direct user control of their numbers 2. Multiple services attached to a single number where the service = providers for each of the services may be different. I also suspect that we=92re going to change the current mechanisms for = inventory control of numbers, heading towards either =93centralized=94 = inventory, with service providers or users requesting one number at a = time from common inventory, or at least much smaller units of inventory = allocation from the numbering authorities. Brian On Oct 16, 2014, at 3:16 PM, Henning Schulzrinne = wrote: > My hope is that similar protocols would work, maybe as subsets or with = additions, for both the hierarchical and "flat" case. It is at least = possible that we'll see combinations, e.g., flat at the top and trees = below, or a tree with some flat parts in a branch (e.g., between = replicas or between parts of an organization). >=20 > I'm implicitly assuming that the actors are cooperative, i.e., they = authenticate themselves, and they don't intentionally try to inflict = damage. >=20 > For routing, I wonder whether we'll see both: some entries will = contain an initial routing contact (a SIP URL, some ENUM root, etc.), = others may not. Would it be sufficient to provide this as optional data, = recognizing that it may not be always present? >=20 > Is it sufficient to have one query protocol for everyone, where the = information that is returned depends on who is asking? (For example, the = assignee of a number gets lots of information, an anonymous querier may = only get the rough equivalent of DNS whois, i.e., contact information = for the assignee.) >=20 > Since policies and business arrangements are still evolving, I'm = trying to explore flexible options, so that we don't end up in embedding = too many assumptions, as, to some extent, ENUM did, where the assumption = seems to have been that of a single kind of querier. >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of PFAUTZ, PENN L = [pp3129@att.com] > Sent: Thursday, October 16, 2014 3:06 PM > To: modern@ietf.org > Subject: Re: [Modern] Zombie numbering issues >=20 > As much as it's fun to discuss what protocols we have in the closet = that might be useful or not, am I wrong for thinking we need to start = with some assumptions about the architecture and what it has to do? >=20 > I agree that that number administration regime is a national matter = but perhaps we can still devise a generic framework that will be = attractive to right-thinking regulators everywhere :-) > So, > Based on the Workshop back in March can we assume that there will be a = numbering registry that combines resource allocation and porting = (delegation) for all types of E.164 numbers? This is not saying whether = the registry is centralized or distributed a la Whitespaces. So we'll = need some kind of registrar-registry protocol. What are the necessary = characteristics? Can we assume anything about the actors? >=20 > Can we also assume that the registry is the apex for distribution of = routing formation? I say apex because one decision is whether the = registry contains such information (and potentially service logic to = derive it) itself or delegates that and potentially other, e.g., = identity related information to other parties. Depending on the answer, = different protocols may be appropriate. > If there is delegation there might be different protocols involved at = different stages of the resolution to the desired information. >=20 > Penn Pfautz >=20 >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Oct 16 12:36:41 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594191A8880 for ; Thu, 16 Oct 2014 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 H6m9siWBNccY for ; Thu, 16 Oct 2014 12:36:35 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F65F1A8876 for ; Thu, 16 Oct 2014 12:36:35 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 34e10445.2b34ec01f940.6152132.00-2431.17345020.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 16 Oct 2014 19:36:35 +0000 (UTC) X-MXL-Hash: 54401e436b4a1cf5-fb6d3f513d0f8f371ff5a9f065f104f121e8f3e8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e3e10445.0.6152094.00-2234.17344897.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 16 Oct 2014 19:36:31 +0000 (UTC) X-MXL-Hash: 54401e3f404e6c74-e4a175b5b89a9f8f9b70a33de08964a665a21708 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 s9GJaUbC028702; Thu, 16 Oct 2014 15:36:30 -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 s9GJaJLV028584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Oct 2014 15:36:25 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 16 Oct 2014 19:36:09 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 15:36:09 -0400 From: "PFAUTZ, PENN L" To: Henning Schulzrinne , "modern@ietf.org" Thread-Topic: [Modern] Zombie numbering issues Thread-Index: AQHP6L/ILNUG0QEXpUWV4L2Bl7PO+pwzEaLwgABLZwD//7/UEA== Date: Thu, 16 Oct 2014 19:36:08 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605741076@MISOUT7MSGUSRDD.ITServices.sbc.com> References: , <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] 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-AnalysisOut: [v=2.0 cv=dshs/Sc4 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=72uK5NNhlwxiF83P6zcA:9 a=CjuIK1q_8ugA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=Hz7IrDYlS0cA:10 a=1JBD5sPB9GTGy5VT:21 a=rwZFCgs] X-AnalysisOut: [0FH_ZaooK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/toibOLU7lxYt-F8q44xtWF9_pwo Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:36:40 -0000 See in-line -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Thursday, October 16, 2014 3:17 PM To: PFAUTZ, PENN L; modern@ietf.org Subject: RE: [Modern] Zombie numbering issues My hope is that similar protocols would work, maybe as subsets or with addi= tions, for both the hierarchical and "flat" case. It is at least possible t= hat we'll see combinations, e.g., flat at the top and trees below, or a tre= e with some flat parts in a branch (e.g., between replicas or between parts= of an organization). I'm implicitly assuming that the actors are cooperative, i.e., they authent= icate themselves, and they don't intentionally try to inflict damage. For routing, I wonder whether we'll see both: some entries will contain an = initial routing contact (a SIP URL, some ENUM root, etc.), others may not. = Would it be sufficient to provide this as optional data, recognizing that i= t may not be always present? >>perhaps the right approach would be to allow either a simple direct answe= r OR a reference (for example, like DNS does). >> I do want to keep policy and service logic at least out of any *common* = infrastructure. I already find in bi-lateral=20 >> interconnection negotiations (albeit for "aggregate" routing methods) th= at the variations in routing policy desired by different >>SPs is such that anticipating them all in a shared infrastructure will be= problematic. Keeping such logic in the hands of the >> number delegate will maximize flexibility and minimize what we have to a= gree on to get started.=20 Is it sufficient to have one query protocol for everyone, where the informa= tion that is returned depends on who is asking? (For example, the assignee = of a number gets lots of information, an anonymous querier may only get the= rough equivalent of DNS whois, i.e., contact information for the assignee.= ) Since policies and business arrangements are still evolving, I'm trying to = explore flexible options, so that we don't end up in embedding too many ass= umptions, as, to some extent, ENUM did, where the assumption seems to have = been that of a single kind of querier. ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of PFAUTZ, PENN L [pp3129@= att.com] Sent: Thursday, October 16, 2014 3:06 PM To: modern@ietf.org Subject: Re: [Modern] Zombie numbering issues As much as it's fun to discuss what protocols we have in the closet that m= ight be useful or not, am I wrong for thinking we need to start with some a= ssumptions about the architecture and what it has to do? I agree that that number administration regime is a national matter but per= haps we can still devise a generic framework that will be attractive to rig= ht-thinking regulators everywhere :-) So, Based on the Workshop back in March can we assume that there will be a numb= ering registry that combines resource allocation and porting (delegation) f= or all types of E.164 numbers? This is not saying whether the registry is c= entralized or distributed a la Whitespaces. So we'll need some kind of regi= strar-registry protocol. What are the necessary characteristics? Can we ass= ume anything about the actors? Can we also assume that the registry is the apex for distribution of routin= g formation? I say apex because one decision is whether the registry contai= ns such information (and potentially service logic to derive it) itself or = delegates that and potentially other, e.g., identity related information to= other parties. Depending on the answer, different protocols may be appropr= iate. If there is delegation there might be different protocols involved at diffe= rent stages of the resolution to the desired information. Penn Pfautz _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern From nobody Thu Oct 16 12:41:24 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDA1A88A6 for ; Thu, 16 Oct 2014 12:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5VSQ14V4Peo6 for ; Thu, 16 Oct 2014 12:41:16 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 75DBA1A88A5 for ; Thu, 16 Oct 2014 12:41:16 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "PFAUTZ, PENN L" , "modern@ietf.org" Thread-Topic: [Modern] Zombie numbering issues Thread-Index: AQHP6L+/k7zYAM8LFEGMVjP9RQxsP5wzWhyA//+95eSAAEprAP//vXTb Date: Thu, 16 Oct 2014 19:41:15 +0000 References: , <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> , <38726EDA2109264987B45E29E758C4D605741076@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605741076@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Zmu29P1I905XgTQ1MA3NxQq3lZk Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:41:18 -0000 My only quick comment is that I think it's generally a good idea to allow s= imple cases to be handled with minimal complexity. If, for example, the pro= tocol allows, but does not mandate, disclosing a contact point, this will m= ake it much easier for small entities that then only have to run a SIP serv= er, without setting up lots of additional machinery. (Somewhat similar to t= he current DNS model, where the NS records can be found easily.)=0A= =0A= Large carriers can rely on people making an effort to find them, even if it= 's complicated.=0A= =0A= ________________________________________=0A= From: PFAUTZ, PENN L [pp3129@att.com]=0A= Sent: Thursday, October 16, 2014 3:36 PM=0A= To: Henning Schulzrinne; modern@ietf.org=0A= Subject: RE: [Modern] Zombie numbering issues=0A= =0A= See in-line=0A= =0A= >>perhaps the right approach would be to allow either a simple direct answe= r OR a reference (for example, like DNS does).=0A= >> I do want to keep policy and service logic at least out of any *common* = infrastructure. I already find in bi-lateral=0A= >> interconnection negotiations (albeit for "aggregate" routing methods) th= at the variations in routing policy desired by different=0A= >>SPs is such that anticipating them all in a shared infrastructure will be= problematic. Keeping such logic in the hands of the=0A= >> number delegate will maximize flexibility and minimize what we have to a= gree on to get started.=0A= From nobody Thu Oct 16 12:43:34 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF70F1A88BE for ; Thu, 16 Oct 2014 12:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TTQS2uLPrjsg for ; Thu, 16 Oct 2014 12:43:29 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0511A88AD for ; Thu, 16 Oct 2014 12:43:25 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id ddf10445.2b3546616940.6156952.00-2450.17358906.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 16 Oct 2014 19:43:25 +0000 (UTC) X-MXL-Hash: 54401fdd4f96000d-248201401aad132e985a8f28d2b6e5d9f786c6f2 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id bdf10445.0.6156916.00-2204.17358800.nbfkord-smmo06.seg.att.com (envelope-from ); Thu, 16 Oct 2014 19:43:24 +0000 (UTC) X-MXL-Hash: 54401fdc49e28625-65baa2f0806889b5df70993480949e99969ea1fd 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 s9GJhMtW006417; Thu, 16 Oct 2014 15:43:23 -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 s9GJhDdV006286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Oct 2014 15:43:15 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 16 Oct 2014 19:42:57 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 15:42:56 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Zombie numbering issues Thread-Index: AQHP6L/ILNUG0QEXpUWV4L2Bl7PO+pwzEaLwgABLZwCAAAN3AP//v+Kw Date: Thu, 16 Oct 2014 19:42:56 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D6057410A3@MISOUT7MSGUSRDD.ITServices.sbc.com> References: , <38726EDA2109264987B45E29E758C4D605741014@MISOUT7MSGUSRDD.ITServices.sbc.com> <02A77C15-0CE8-47E3-A4B2-D74BC08E135C@brianrosen.net> In-Reply-To: <02A77C15-0CE8-47E3-A4B2-D74BC08E135C@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] 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-AnalysisOut: [v=2.0 cv=dshs/Sc4 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HLLxP2VMA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=vVq2kAZnCKd7l_-u7Y4A:9 a=CjuIK1q_] X-AnalysisOut: [8ugA:10 a=-zy3ex45pM4A:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA] X-AnalysisOut: [:10 a=UmpZYVK4PinxrMcR:21 a=KImzPXvMRuxF507p:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/rG0jDBx_P7B5byyuYIt2tS_tHR0 Cc: "modern@ietf.org" Subject: Re: [Modern] Zombie numbering issues X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:43:31 -0000 Brian: I for one do believe there should be one (potentially distributed) registry= and not a separate routing database. As I indicated that registry might or= might not supply routing information directly depending on number delegate= (whether end user or SP) choice and complexity. Re number 2 below I understand the desire but remind you that then we have = to get into service definition - maybe there is a way to fudge that? I agree w/r/t to inventory; a well-designed system should allow SPs to disp= ense with inventory. Penn -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, October 16, 2014 3:29 PM To: Henning Schulzrinne Cc: PFAUTZ, PENN L; modern@ietf.org Subject: Re: [Modern] Zombie numbering issues I definitely think it's an open architectural question of whether there is = one database that has "ownership" information, and another that has routing= . In some cases, of course, knowledge of ownership is enough information t= o complete routing, so that argues there is one database. But we should se= riously consider if that is what we want. I do think that we want to take into consideration that we're clearly heade= d towards two complications we don't consider today: 1. More direct user control of their numbers 2. Multiple services attached to a single number where the service provider= s for each of the services may be different. I also suspect that we're going to change the current mechanisms for invent= ory control of numbers, heading towards either "centralized" inventory, wit= h service providers or users requesting one number at a time from common in= ventory, or at least much smaller units of inventory allocation from the nu= mbering authorities. Brian On Oct 16, 2014, at 3:16 PM, Henning Schulzrinne wrote: > My hope is that similar protocols would work, maybe as subsets or with ad= ditions, for both the hierarchical and "flat" case. It is at least possible= that we'll see combinations, e.g., flat at the top and trees below, or a t= ree with some flat parts in a branch (e.g., between replicas or between par= ts of an organization). >=20 > I'm implicitly assuming that the actors are cooperative, i.e., they authe= nticate themselves, and they don't intentionally try to inflict damage. >=20 > For routing, I wonder whether we'll see both: some entries will contain a= n initial routing contact (a SIP URL, some ENUM root, etc.), others may not= . Would it be sufficient to provide this as optional data, recognizing that= it may not be always present? >=20 > Is it sufficient to have one query protocol for everyone, where the infor= mation that is returned depends on who is asking? (For example, the assigne= e of a number gets lots of information, an anonymous querier may only get t= he rough equivalent of DNS whois, i.e., contact information for the assigne= e.) >=20 > Since policies and business arrangements are still evolving, I'm trying t= o explore flexible options, so that we don't end up in embedding too many a= ssumptions, as, to some extent, ENUM did, where the assumption seems to hav= e been that of a single kind of querier. >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of PFAUTZ, PENN L [pp312= 9@att.com] > Sent: Thursday, October 16, 2014 3:06 PM > To: modern@ietf.org > Subject: Re: [Modern] Zombie numbering issues >=20 > As much as it's fun to discuss what protocols we have in the closet that= might be useful or not, am I wrong for thinking we need to start with some= assumptions about the architecture and what it has to do? >=20 > I agree that that number administration regime is a national matter but p= erhaps we can still devise a generic framework that will be attractive to r= ight-thinking regulators everywhere :-) > So, > Based on the Workshop back in March can we assume that there will be a nu= mbering registry that combines resource allocation and porting (delegation)= for all types of E.164 numbers? This is not saying whether the registry is= centralized or distributed a la Whitespaces. So we'll need some kind of re= gistrar-registry protocol. What are the necessary characteristics? Can we a= ssume anything about the actors? >=20 > Can we also assume that the registry is the apex for distribution of rout= ing formation? I say apex because one decision is whether the registry cont= ains such information (and potentially service logic to derive it) itself o= r delegates that and potentially other, e.g., identity related information = to other parties. Depending on the answer, different protocols may be appro= priate. > If there is delegation there might be different protocols involved at dif= ferent stages of the resolution to the desired information. >=20 > Penn Pfautz >=20 >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Thu Oct 16 12:55:32 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B980D1A88DE for ; Thu, 16 Oct 2014 12:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rKVEi6AaN6-B for ; Thu, 16 Oct 2014 12:55:28 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id BF3531A88D9 for ; Thu, 16 Oct 2014 12:55:26 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "PFAUTZ, PENN L" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oog== Date: Thu, 16 Oct 2014 19:55:25 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/7349ArZtKJr8rw7owDAHsMM1La0 Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:55:29 -0000 We have some precedence for service definitions in the caller preferences w= ork, for standards-based services. It's relatively easy, I think, if the se= rvices are clearly separated ("voice only" + "text only"). Given modern mul= timedia services, I'm not sure how common this is going to be, given that e= very service will likely support audio, video and text.=0A= =0A= For proprietary services, this is probably pretty much a name registration = problem ("Skype", "Facebook").=0A= =0A= ________________________________________=0A= From: PFAUTZ, PENN L [pp3129@att.com]=0A= Sent: Thursday, October 16, 2014 3:42 PM=0A= To: Brian Rosen; Henning Schulzrinne=0A= Cc: modern@ietf.org=0A= Subject: RE: [Modern] Zombie numbering issues=0A= =0A= =0A= Re number 2 below I understand the desire but remind you that then we have = to get into service definition - maybe there is a way to fudge that?=0A= From nobody Thu Oct 16 13:43:24 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55E1A897A for ; Thu, 16 Oct 2014 13:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 dxEDo0XY9zFc for ; Thu, 16 Oct 2014 13:43:12 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D221A892E for ; Thu, 16 Oct 2014 13:43:12 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id m20so3525562qcx.15 for ; Thu, 16 Oct 2014 13:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fzgN+icT78w+stmcoTIHXtGSmUBWru7A7hLOoMZZFF8=; b=DgJt4txpXDoMRil56YTHojU44jS8sE1ebOWCmPiubcljL54oz1YiKlMOYWekPtyHbc YKjuooJzKn/IPtxGAgQwhkaElcsTKHLSXzFaALsInJVx432AjdgwUPLSj/GV9NsLK2Wi zH9aWnWuGVEc0kKFrocmtmkGb6k9XxDNI1aWYr33YD3UPqwQK4dJdHUZVm59WWd2C5FJ 4UQl0DSOn1wFFMg4ngxyZmarO5IE33CgWOadQ4Ua8iO3C1SvhpxMzgZCgfcQretPWZyw HHWQkeZZYFbRf9zhgH5BeYAzopUWRHTToesHQ5WjVtJZAmJyvjDb5MDNJPg5BRedxKWq RA8A== X-Gm-Message-State: ALoCoQk+6OpBRHxgvnBUgV/JsYBjq+IJ40ze87R+SDxzAJlofeHBJXzw1puXV5Q2W8D8HJERjWXv X-Received: by 10.224.36.200 with SMTP id u8mr5718402qad.47.1413492191843; Thu, 16 Oct 2014 13:43:11 -0700 (PDT) Received: from [10.33.193.15] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id c17sm9346592qaw.8.2014.10.16.13.43.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 13:43:10 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Thu, 16 Oct 2014 16:43:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/XCSWsH5IBRh3VRI2BLS44qVrFSA Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:43:13 -0000 Like it or not, we have OTT services using the same TN as the service = provider=92s services, even if there is overlap. That is, I suspect, = exactly what Penn was getting at. Brian On Oct 16, 2014, at 3:55 PM, Henning Schulzrinne = wrote: > We have some precedence for service definitions in the caller = preferences work, for standards-based services. It's relatively easy, I = think, if the services are clearly separated ("voice only" + "text = only"). Given modern multimedia services, I'm not sure how common this = is going to be, given that every service will likely support audio, = video and text. >=20 > For proprietary services, this is probably pretty much a name = registration problem ("Skype", "Facebook"). >=20 > ________________________________________ > From: PFAUTZ, PENN L [pp3129@att.com] > Sent: Thursday, October 16, 2014 3:42 PM > To: Brian Rosen; Henning Schulzrinne > Cc: modern@ietf.org > Subject: RE: [Modern] Zombie numbering issues >=20 >=20 > Re number 2 below I understand the desire but remind you that then we = have to get into service definition - maybe there is a way to fudge = that? From nobody Thu Oct 16 17:13:53 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566F91A1B65 for ; Thu, 16 Oct 2014 17:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 W9aiGxG3UvEc for ; Thu, 16 Oct 2014 17:13:50 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id D3F5C1A87A6 for ; Thu, 16 Oct 2014 17:13:49 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zs= Date: Fri, 17 Oct 2014 00:13:47 +0000 References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/as3LDOpLucT-I82z80NUZgpzViA Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:13:51 -0000 If they are both SIP services (say), I'm not sure how you'd distinguish the= m (and make the call work without some voice IVR like "The number you have = reached has multiple services. Would you like to talk to 201 555 1234 via A= T&T, Vonage or Facebook?"=0A= =0A= As far as I can tell today, a single number today only has one provider. Or= are you talking about the case where I can use my SMS number as an Apple i= Chat identifier, which then bypasses SMS?=0A= =0A= ________________________________________=0A= From: Brian Rosen [br@brianrosen.net]=0A= Sent: Thursday, October 16, 2014 4:43 PM=0A= To: Henning Schulzrinne=0A= Cc: PFAUTZ, PENN L; modern@ietf.org=0A= Subject: Re: [Modern] Services=0A= =0A= Like it or not, we have OTT services using the same TN as the service provi= der=92s services, even if there is overlap. That is, I suspect, exactly wh= at Penn was getting at.=0A= =0A= Brian=0A= From nobody Thu Oct 16 17:17:15 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF511A8AC6 for ; Thu, 16 Oct 2014 17:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_AMBIEN=0.552, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 PKfh3g7TOLrR for ; Thu, 16 Oct 2014 17:17:13 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id DF0CE1A8A58 for ; Thu, 16 Oct 2014 17:17:12 -0700 (PDT) Received: (qmail 26574 invoked by uid 0); 17 Oct 2014 00:17:08 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 17 Oct 2014 00:17:08 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 40H41p00L1MNPNq010H7XX; Thu, 16 Oct 2014 18:17:07 -0600 X-Authority-Analysis: v=2.1 cv=Tr912lnh c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=HLLxP2VMAAAA:8 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=s7kaxF5nE7qQtzy_ugsA:9 a=UEZnLJIWFb4C8Wdic9J8r10ra3M=:19 a=tzoD8FdxD13T9nck:21 a=exxvkVMpxpy14WQV:21 a=wPNLvfGTeEIA:10 a=-zy3ex45pM4A:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 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:Message-ID:To:From:Subject:Date; bh=HB5Ax7u2GgLr0EQZkzQOiJBljAxiAMvMF0PyBoY4lTI=; b=YhVB+korsAfRi8zfy5osBNfpnfNhx2LAQpi88Pau88XLLWcZ/EbzYcOC1weRCSVuQAprycAXmZ6FsIdRycWmZihm3o8EcH4UUDKu9zCzfj8ZG/Q5XhOT7ZclYtRZya52; Received: from [72.66.64.164] (port=54677 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XevE9-0002ye-2V for modern@ietf.org; Thu, 16 Oct 2014 18:17:05 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Thu, 16 Oct 2014 20:17:00 -0400 From: Richard Shockey To: "modern@ietf.org" Message-ID: Thread-Topic: What are we trying to do? Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/G6QvjFtaRDZYP76gCQy8qwV7jFU Subject: [Modern] What are we trying to do? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:17:14 -0000 Well I like OTT services just fine but I also like provider delivered services as well. Any reasonable survey of the real time communications market would tell you that the carriers are still making A LOT of money delivering voice and other stuff using E.164 numbering. I=B9m happy to pay ATT and Verizon BTW for mobile and landline Public SIP Telephony Networking. OTT has certainly dented the market but here in North America OTT is really no more than 7% of the total minutes. That is from FCC CRTC OFCOM data and Telegeography etc. International calling is different since there is such a massive arbitrage play still there. That said the Problem Statement and Requirements we are generally looking at is how do you preserve protect and defend the service model of any to any that is still governed by E.164 numbering and by inference that includes emergency calling. That is a value proposition worth defending and worth serious thought. That was the purpose of Hennings Workshop on Numbering at the FCC and presumably we want to take this conversation somewhere. We have made a start with STIR ..eventually we may want to look at a more comprehensive view of Calling Party Name. Something for lack of a better term ( we don=B9t have Hardriel any more) I called CNAM +. Naming and Addressing is central to any network operation and the IETF has certainly dealt with the protocol issues surrounding domain names. I certainly tried to look at number provisioning in DRINKS (I wrote the charter) but lets not go there. It is perfectly reasonable and prudent for the RAI area to provide tools for National Numbering Administration if ..if we can gather support from other National Numbering Adminstrations. The logical first step is the usual Problem Statement and Requirements that we are all familiar with. With that there are folks at the US FCC that could be helpful. Certainly some of us know other NRA=B9s etc and frankly this is exactly the kind of project that the Internet Society should be involved with. BTW I live 5 minutes from their HQ =8A oh btw. If you are following the ongoing Ebola story ISOC=B9s HQ is directly across the street on Whelie here in Reston from where the first reported case of Ebola was reported in the United States and was the subject of the famous book Hot Zone by Richard Preston. =20 On 10/16/14, 4:43 PM, "Brian Rosen" wrote: >Like it or not, we have OTT services using the same TN as the service >provider=B9s services, even if there is overlap. That is, I suspect, >exactly what Penn was getting at. > >Brian > >On Oct 16, 2014, at 3:55 PM, Henning Schulzrinne > wrote: > >> We have some precedence for service definitions in the caller >>preferences work, for standards-based services. It's relatively easy, I >>think, if the services are clearly separated ("voice only" + "text >>only"). Given modern multimedia services, I'm not sure how common this >>is going to be, given that every service will likely support audio, >>video and text. >>=20 >> For proprietary services, this is probably pretty much a name >>registration problem ("Skype", "Facebook"). >>=20 >> ________________________________________ >> From: PFAUTZ, PENN L [pp3129@att.com] >> Sent: Thursday, October 16, 2014 3:42 PM >> To: Brian Rosen; Henning Schulzrinne >> Cc: modern@ietf.org >> Subject: RE: [Modern] Zombie numbering issues >>=20 >>=20 >> Re number 2 below I understand the desire but remind you that then we >>have to get into service definition - maybe there is a way to fudge that? > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Fri Oct 17 05:51:01 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C461ACD50 for ; Fri, 17 Oct 2014 05:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 2p-xJzjOxeF3 for ; Fri, 17 Oct 2014 05:50:56 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4211ACD4B for ; Fri, 17 Oct 2014 05:50:56 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id w8so421290qac.23 for ; Fri, 17 Oct 2014 05:50:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=9JpC1TBZpSIEkQImw7I8YZMNy8+PmrHl/j+kndzJwxc=; b=eiw8yt2X4QXiWGVpQ6+49dkYEPy6igHXAQWC15ehdZ1zLCg9EiJSo1LIDIsrJwl8TJ 9MxwRgfws2bKXZTr2I6M3OsypCX/r0QPfSpwMsg/l2mMBdHQ6m6dDfdyesbqU6Sc3/Eh Pj9JtCZWZFcNBy48P7SVVWKVIGpvm4rEgRS1kdlx2uqR6trFJr2DMEM8mAQTDF0ddDy5 r56+MU2D40SGqKZsW7Fd/zCNKD0Af5AfRPqp4MjVqT1v2pHT7nou+tfcAPr1xSM5dnbZ M4DCs3PZsQ/asvEVXIRRPO9PXPdQV1z32ceXmhvhOJ+kyba2oFj25tn9jXYEJvvPN/QT SpTQ== X-Gm-Message-State: ALoCoQnRP/zytKnaDQbmGZNadMsSD68iubZh6ig6KdYHyZdbdIRGj/SQXgRM50ftUBv+DE/jWIkF X-Received: by 10.224.138.2 with SMTP id y2mr11742584qat.58.1413550255724; Fri, 17 Oct 2014 05:50:55 -0700 (PDT) Received: from [10.33.193.15] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id q12sm815295qan.37.2014.10.17.05.50.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 05:50:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Fri, 17 Oct 2014 08:50:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: , To: Henning Schulzrinne X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/4_MborhHl6Fh66PRIhODamHD1mE Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:50:58 -0000 Yes, among many other services that use your phone number as an = identifier. I think the iMessage service is very interesting, because = it really does use the TN as the identifier. It has an association = between a TN and an AppleId, which it then uses to extend who and how it = contacts other users, but that service is the =93text=94 supplier for = the device, and it may make use of other services tied to the TN, such = as the SMS service. =20 I think, long term, that a service like voice (or video) really will be = separate from a service like text, and users will be free to choose = whatever service provider they wish. I think the user interfaces for = such services may well be separate from the service providers. Of = course bundles of services and user interfaces will continue to exist, = but I think the notion that there is one service provider per TN has = long past, and I would like to make sure that the TN is portable for all = such services that use it. Brian On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne = wrote: > If they are both SIP services (say), I'm not sure how you'd = distinguish them (and make the call work without some voice IVR like = "The number you have reached has multiple services. Would you like to = talk to 201 555 1234 via AT&T, Vonage or Facebook?" >=20 > As far as I can tell today, a single number today only has one = provider. Or are you talking about the case where I can use my SMS = number as an Apple iChat identifier, which then bypasses SMS? >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Thursday, October 16, 2014 4:43 PM > To: Henning Schulzrinne > Cc: PFAUTZ, PENN L; modern@ietf.org > Subject: Re: [Modern] Services >=20 > Like it or not, we have OTT services using the same TN as the service = provider=92s services, even if there is overlap. That is, I suspect, = exactly what Penn was getting at. >=20 > Brian From nobody Fri Oct 17 06:00:42 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3C81ACD4F for ; Fri, 17 Oct 2014 06:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=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 x7ieGC-6gw9f for ; Fri, 17 Oct 2014 06:00:29 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE431A88E3 for ; Fri, 17 Oct 2014 06:00:29 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id c9so484663qcz.22 for ; Fri, 17 Oct 2014 06:00:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/nVKMcuXig5kRWm3VxeTHA0Hgo3kLA8XKh3jAoc0Rk0=; b=G/C5+xHr92CApMltfAcP8qUjNjPm+HVLp2VkTLUoZwya3iqgzyZ0kTxEmjFeEZQQDX 6RTfkD2XUr25kcd+JuuEouMLvu46ZQv3Mpxy39k1x+4fwfCoAH9Qbrv5muF7Ob8+igrl b0QH9Iaq8xKZDmv6sWtqJO19yCnjwWMVzlVgxk/dZDEUfMVxsNitQUykOfhuWn4+LQwa 4L8IqF5/RO3WOjwWtrkOgfzqIjvRoGPR/QFh3sK4He3ClWZW3R4i9b+oXJMoBMreiIgA MOJavMgvpv1r7YGN58SI24cje6RhJzy7Tv/gP5Gp0kjjoXFKBlqy8KLE+Y1vi8znvV0R 9//g== X-Gm-Message-State: ALoCoQmH2r41H5LhQ4O8l4m4l8EQjboVuc19ZXU5fdK22h8EK2fhmUtD9bCz2mSwHSS/bB7u6QHj X-Received: by 10.229.33.196 with SMTP id i4mr11866050qcd.4.1413550828497; Fri, 17 Oct 2014 06:00:28 -0700 (PDT) Received: from [10.33.193.15] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id d68sm846770qga.17.2014.10.17.06.00.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 06:00:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Rosen In-Reply-To: Date: Fri, 17 Oct 2014 09:00:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Shockey X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/seKJ97QCo6zUTOqS8-_b-6hoVFQ Cc: "modern@ietf.org" Subject: Re: [Modern] What are we trying to do? X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:00:32 -0000 Well I like OTT and =93provider=94 services too, and don=92t see what my = personal preference has to do with it. In Voice OTT is pretty small, in = text, it=92s pretty big, in video, it=92s overwhelming. So? I think the TN is a resource that historical is, and will be managed by = regulators. I think that the current management methods are not = sufficient for the near and long term future of services that use a TN = as an identifier. I think the IETF is the proper venue for global TN = based addressing for services delivered over an IP network, which these = days is just about all services. I think allocation (how you get a TN), = =93ownership=94 (who actually controls the TN, here meaning =93the" SP, = which is what we have now, or the user), mapping of the TN to services, = routing to the services, and ancillary information attached to the TN = (like name) are reasonable scope issues, recognizing that one size won=92t= fit all because we will have regulators who don=92t all see things the = same way. Brian On Oct 16, 2014, at 8:17 PM, Richard Shockey wrote: >=20 > Well I like OTT services just fine but I also like provider delivered > services as well. Any reasonable survey of the real time = communications > market would tell you that the carriers are still making A LOT of = money > delivering voice and other stuff using E.164 numbering. I=B9m happy = to pay > ATT and Verizon BTW for mobile and landline Public SIP Telephony > Networking. >=20 > OTT has certainly dented the market but here in North America OTT is > really no more than 7% of the total minutes. That is from FCC CRTC = OFCOM > data and Telegeography etc. International calling is different since = there > is such a massive arbitrage play still there. >=20 > That said the Problem Statement and Requirements we are generally = looking > at is how do you preserve protect and defend the service model of any = to > any that is still governed by E.164 numbering and by inference that > includes emergency calling. That is a value proposition worth = defending > and worth serious thought. >=20 > That was the purpose of Hennings Workshop on Numbering at the FCC and > presumably we want to take this conversation somewhere. We have made = a > start with STIR ..eventually we may want to look at a more = comprehensive > view of Calling Party Name. Something for lack of a better term ( we = don=B9t > have Hardriel any more) I called CNAM +. >=20 > Naming and Addressing is central to any network operation and the IETF = has > certainly dealt with the protocol issues surrounding domain names. I > certainly tried to look at number provisioning in DRINKS (I wrote the > charter) but lets not go there. It is perfectly reasonable and = prudent > for the RAI area to provide tools for National Numbering = Administration if > ..if we can gather support from other National Numbering = Adminstrations. >=20 > The logical first step is the usual Problem Statement and Requirements > that we are all familiar with. With that there are folks at the US FCC > that could be helpful. Certainly some of us know other NRA=B9s etc = and > frankly this is exactly the kind of project that the Internet Society > should be involved with. >=20 > BTW I live 5 minutes from their HQ =8A oh btw. If you are following = the > ongoing Ebola story ISOC=B9s HQ is directly across the street on = Whelie here > in Reston from where the first reported case of Ebola was reported in = the > United States and was the subject of the famous book Hot Zone by = Richard > Preston. =20 >=20 >=20 >=20 >=20 >=20 > On 10/16/14, 4:43 PM, "Brian Rosen" wrote: >=20 >> Like it or not, we have OTT services using the same TN as the service >> provider=B9s services, even if there is overlap. That is, I suspect, >> exactly what Penn was getting at. >>=20 >> Brian >>=20 >> On Oct 16, 2014, at 3:55 PM, Henning Schulzrinne >> wrote: >>=20 >>> We have some precedence for service definitions in the caller >>> preferences work, for standards-based services. It's relatively = easy, I >>> think, if the services are clearly separated ("voice only" + "text >>> only"). Given modern multimedia services, I'm not sure how common = this >>> is going to be, given that every service will likely support audio, >>> video and text. >>>=20 >>> For proprietary services, this is probably pretty much a name >>> registration problem ("Skype", "Facebook"). >>>=20 >>> ________________________________________ >>> From: PFAUTZ, PENN L [pp3129@att.com] >>> Sent: Thursday, October 16, 2014 3:42 PM >>> To: Brian Rosen; Henning Schulzrinne >>> Cc: modern@ietf.org >>> Subject: RE: [Modern] Zombie numbering issues >>>=20 >>>=20 >>> Re number 2 below I understand the desire but remind you that then = we >>> have to get into service definition - maybe there is a way to fudge = that? >>=20 >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Fri Oct 17 06:48:47 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1563A1ACDD1 for ; Fri, 17 Oct 2014 06:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.69 X-Spam-Level: * X-Spam-Status: No, score=1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 QOEHvg4Dvlce for ; Fri, 17 Oct 2014 06:48:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D4A1ACDDA for ; Fri, 17 Oct 2014 06:48:43 -0700 (PDT) Received: from BN1AFFO11FD013.protection.gbl (10.58.52.34) by BN1AFFO11HUB050.protection.gbl (10.58.52.180) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Fri, 17 Oct 2014 13:48:42 +0000 Received: from plsasdm2.corp.sprint.com (144.230.168.26) by BN1AFFO11FD013.mail.protection.outlook.com (10.58.52.73) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Fri, 17 Oct 2014 13:48:42 +0000 Received: from pdaasen1.corp.sprint.com (mailhost.it.sprintspectrum.com [144.226.111.128]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9HDmcKv014696 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 08:48:41 -0500 Received: from PLSWE13M07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by pdaasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9HDmbuK020796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2014 08:48:40 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 17 Oct 2014 08:48:39 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Fri, 17 Oct 2014 08:48:39 -0500 From: "Gorman, Pierce A [NTK]" To: Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAShIAP//vCgg Date: Fri, 17 Oct 2014 13:48:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.168.26; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(189002)(51704005)(24454002)(377454003)(199003)(120916001)(47776003)(97736003)(76176999)(46406003)(54356999)(106116001)(50986999)(106466001)(6806004)(64706001)(99396003)(26826002)(80022003)(50466002)(95666004)(2656002)(19580395003)(76482002)(87936001)(93886004)(33646002)(23726002)(31966008)(92566001)(20776003)(108616004)(21056001)(85306004)(19580405001)(77096002)(15975445006)(4396001)(46102003)(44976005)(107046002)(97756001)(86362001)(84676001)(68736004)(85852003)(276003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB050; H:plsasdm2.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB050; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0367A50BB1 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.26 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.26; helo=plsasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.26) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/KtzP89ZPILR8H8ifxlKiHd4D9lQ Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:48:46 -0000 "... but I think the notion that there is one service provider per TN has l= ong past, and I would like to make sure that the TN is portable for all suc= h services that use it." HEAR HEAR!!! Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Brian Rosen Sent: October 17, 2014 7:51 AM To: Henning Schulzrinne Cc: modern@ietf.org; PFAUTZ, PENN L Subject: Re: [Modern] Services Yes, among many other services that use your phone number as an identifier.= I think the iMessage service is very interesting, because it really does= use the TN as the identifier. It has an association between a TN and an A= ppleId, which it then uses to extend who and how it contacts other users, b= ut that service is the "text" supplier for the device, and it may make use = of other services tied to the TN, such as the SMS service. I think, long term, that a service like voice (or video) really will be sep= arate from a service like text, and users will be free to choose whatever s= ervice provider they wish. I think the user interfaces for such services m= ay well be separate from the service providers. Of course bundles of servi= ces and user interfaces will continue to exist, but I think the notion that= there is one service provider per TN has long past, and I would like to ma= ke sure that the TN is portable for all such services that use it. Brian On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne wrote: > If they are both SIP services (say), I'm not sure how you'd distinguish t= hem (and make the call work without some voice IVR like "The number you hav= e reached has multiple services. Would you like to talk to 201 555 1234 via= AT&T, Vonage or Facebook?" > > As far as I can tell today, a single number today only has one provider. = Or are you talking about the case where I can use my SMS number as an Apple= iChat identifier, which then bypasses SMS? > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Thursday, October 16, 2014 4:43 PM > To: Henning Schulzrinne > Cc: PFAUTZ, PENN L; modern@ietf.org > Subject: Re: [Modern] Services > > Like it or not, we have OTT services using the same TN as the service pro= vider's services, even if there is overlap. That is, I suspect, exactly wh= at Penn was getting at. > > Brian _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Oct 17 12:22:25 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B6A1A19EB for ; Fri, 17 Oct 2014 12:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.69 X-Spam-Level: * X-Spam-Status: No, score=1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 U_UQ1NzAUswp for ; Fri, 17 Oct 2014 12:22:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDA21A03A9 for ; Fri, 17 Oct 2014 12:22:21 -0700 (PDT) Received: from BN1AFFO11FD057.protection.gbl (10.58.52.32) by BN1AFFO11HUB028.protection.gbl (10.58.52.138) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Fri, 17 Oct 2014 19:22:19 +0000 Received: from plsasdm1.corp.sprint.com (144.230.168.25) by BN1AFFO11FD057.mail.protection.outlook.com (10.58.53.72) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Fri, 17 Oct 2014 19:22:19 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9HJMIdu023283 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 14:22:18 -0500 Received: from PLSWE13M08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9HJMHkd000754 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2014 14:22:17 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 17 Oct 2014 14:21:55 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Fri, 17 Oct 2014 14:21:55 -0500 From: "Gorman, Pierce A [NTK]" To: Henning Schulzrinne , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAUClUA== Date: Fri, 17 Oct 2014 19:21:54 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.168.25; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(199003)(377454003)(189002)(107046002)(76176999)(50986999)(54356999)(77096002)(6806004)(19580395003)(31966008)(95666004)(106466001)(64706001)(20776003)(47776003)(19580405001)(21056001)(44976005)(4396001)(92566001)(86362001)(87936001)(85852003)(2656002)(23726002)(97756001)(15975445006)(46102003)(26826002)(33646002)(106116001)(80022003)(76482002)(50466002)(99396003)(120916001)(108616004)(46406003)(85306004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB028; H:plsasdm1.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpls1.sprint.com; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB028; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0367A50BB1 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.25 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.25; helo=plsasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.25) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/ia-EVifGABSKjcVNiqSq0WjeFDc Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 19:22:23 -0000 IVR wouild be one way. The app could also assume that termination in a lik= e app/provider if available, or one or more preferences settings. E.g., us= e least-cost app/provider. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: October 16, 2014 7:14 PM To: Brian Rosen Cc: modern@ietf.org; PFAUTZ, PENN L Subject: Re: [Modern] Services If they are both SIP services (say), I'm not sure how you'd distinguish the= m (and make the call work without some voice IVR like "The number you have = reached has multiple services. Would you like to talk to 201 555 1234 via A= T&T, Vonage or Facebook?" As far as I can tell today, a single number today only has one provider. Or= are you talking about the case where I can use my SMS number as an Apple i= Chat identifier, which then bypasses SMS? ________________________________________ From: Brian Rosen [br@brianrosen.net] Sent: Thursday, October 16, 2014 4:43 PM To: Henning Schulzrinne Cc: PFAUTZ, PENN L; modern@ietf.org Subject: Re: [Modern] Services Like it or not, we have OTT services using the same TN as the service provi= der's services, even if there is overlap. That is, I suspect, exactly what= Penn was getting at. Brian _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Oct 17 12:27:56 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011091A6F5A for ; Fri, 17 Oct 2014 12:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 blGP_10ErkXi for ; Fri, 17 Oct 2014 12:27:52 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35C61A1A0D for ; Fri, 17 Oct 2014 12:27:46 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 2bd61445.2ae482843940.2100518.00-2450.5968967.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 17 Oct 2014 19:27:46 +0000 (UTC) X-MXL-Hash: 54416db246771eba-605a97271a0d686f2aa7353561d1426667e58969 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id e9d61445.0.2100317.00-2305.5968388.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 17 Oct 2014 19:27:28 +0000 (UTC) X-MXL-Hash: 54416da03b3f1200-dac90a1678546da680c87548fdee3a23afba8043 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 s9HJRPaa027146; Fri, 17 Oct 2014 15:27:26 -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 s9HJR51t026731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Oct 2014 15:27:15 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 17 Oct 2014 19:26:44 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 15:26:43 -0400 From: "PFAUTZ, PENN L" To: "Gorman, Pierce A [NTK]" , Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXA= Date: Fri, 17 Oct 2014 19:26:43 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.44.40] 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-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=hIhwXv9e43IA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=izV7ms69A] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=IHv6eCwUwvwcJv6H] X-AnalysisOut: [Vn0A:9 a=CjuIK1q_8ugA:10 a=DzjOOp_o1eYA:10 a=-Wj7ngL7P9UA:] X-AnalysisOut: [10 a=2aF6lfeD-CsA:10 a=lZB815dzVvQA:10 a=-zy3ex45pM4A:10 a] X-AnalysisOut: [=XwdK-FcbyS67F79I:21 a=c_EsLKTVwDakpxEH:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Ratu2IbbeX_VJ70z37GJ575kzSA Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 19:27:54 -0000 I'm not so sure I agree that a TN should not have a fundamental association= with a single provider, but that's a policy issue. In the DNS an FQDN is d= elegated to a single party. I believe a registry architecture could - and t= he FCC wants it to - be able to accommodate a variety of potential policies= . IFF there were agreement on service definitions, then a registry could h= ave per-service delegation records. So I don't see that this is something t= hat could be or has to be decided now. -----Original Message----- From: Gorman, Pierce A [NTK] [mailto:Pierce.Gorman@sprint.com]=20 Sent: Friday, October 17, 2014 9:49 AM To: Brian Rosen; Henning Schulzrinne Cc: modern@ietf.org; PFAUTZ, PENN L Subject: RE: [Modern] Services "... but I think the notion that there is one service provider per TN has l= ong past, and I would like to make sure that the TN is portable for all suc= h services that use it." HEAR HEAR!!! Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Brian Rosen Sent: October 17, 2014 7:51 AM To: Henning Schulzrinne Cc: modern@ietf.org; PFAUTZ, PENN L Subject: Re: [Modern] Services Yes, among many other services that use your phone number as an identifier.= I think the iMessage service is very interesting, because it really does= use the TN as the identifier. It has an association between a TN and an A= ppleId, which it then uses to extend who and how it contacts other users, b= ut that service is the "text" supplier for the device, and it may make use = of other services tied to the TN, such as the SMS service. I think, long term, that a service like voice (or video) really will be sep= arate from a service like text, and users will be free to choose whatever s= ervice provider they wish. I think the user interfaces for such services m= ay well be separate from the service providers. Of course bundles of servi= ces and user interfaces will continue to exist, but I think the notion that= there is one service provider per TN has long past, and I would like to ma= ke sure that the TN is portable for all such services that use it. Brian On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne wrote: > If they are both SIP services (say), I'm not sure how you'd distinguish t= hem (and make the call work without some voice IVR like "The number you hav= e reached has multiple services. Would you like to talk to 201 555 1234 via= AT&T, Vonage or Facebook?" > > As far as I can tell today, a single number today only has one provider. = Or are you talking about the case where I can use my SMS number as an Apple= iChat identifier, which then bypasses SMS? > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Thursday, October 16, 2014 4:43 PM > To: Henning Schulzrinne > Cc: PFAUTZ, PENN L; modern@ietf.org > Subject: Re: [Modern] Services > > Like it or not, we have OTT services using the same TN as the service pro= vider's services, even if there is overlap. That is, I suspect, exactly wh= at Penn was getting at. > > Brian _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Oct 17 12:46:59 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C721A6FAE for ; Fri, 17 Oct 2014 12:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.69 X-Spam-Level: * X-Spam-Status: No, score=1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 v2k5Nmj5Rke5 for ; Fri, 17 Oct 2014 12:46:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358071A6FB2 for ; Fri, 17 Oct 2014 12:46:55 -0700 (PDT) Received: from BN1BFFO11FD029.protection.gbl (10.58.144.30) by BN1BFFO11HUB020.protection.gbl (10.58.144.167) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Fri, 17 Oct 2014 19:46:52 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BN1BFFO11FD029.mail.protection.outlook.com (10.58.144.92) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Fri, 17 Oct 2014 19:46:52 +0000 Received: from pdaasen1.corp.sprint.com (pdaasen1.corp.sprint.com [144.226.111.128]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9HJkmic026939 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 14:46:51 -0500 Received: from PREWE13M07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by pdaasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9HJkkcb031421 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2014 14:46:50 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 17 Oct 2014 15:46:47 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Fri, 17 Oct 2014 14:46:46 -0500 From: "Gorman, Pierce A [NTK]" To: "PFAUTZ, PENN L" , Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAShIAP//vCgggACycoD//7A9sA== Date: Fri, 17 Oct 2014 19:46:46 +0000 Message-ID: <808a3804e19f42ac8c3a630836c224cd@PLSWE13M08.ad.sprint.com> References: , <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(13464003)(24454002)(51704005)(189002)(199003)(87936001)(2656002)(21056001)(97756001)(26826002)(50466002)(54356999)(92566001)(15975445006)(44976005)(4396001)(6806004)(99396003)(120916001)(80022003)(46102003)(108616004)(76482002)(95666004)(106466001)(106116001)(93886004)(77096002)(85306004)(46406003)(86362001)(85852003)(107046002)(19580395003)(76176999)(50986999)(33646002)(19580405001)(23726002)(31966008)(64706001)(20776003)(47776003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB020; H:pdaasdm2.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpda2.sprint.com; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB020; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0367A50BB1 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/FOfSUC2SqU-UDeaRM1pIb6yaGeA Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 19:46:57 -0000 An FQDN is also not (very) portable. I like the idea that started with por= tability many years ago that a TN can become the virtual property of the us= er, rather than the provider. Its why non-geographic portability appeals t= o me too. Not sure if inter-country portability will happen in my lifetime= (glad there's some roaming), but the idea that an integer can be a univers= al language abstraction of how to contact me multiple different ways is pow= erful. Note: Feel scared and need to disclaim that the opinions expressed herein a= re my own, and should not be considered express or implied opinions of Spri= nt. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: PFAUTZ, PENN L [mailto:pp3129@att.com] Sent: October 17, 2014 2:27 PM To: Gorman, Pierce A [NTK]; Brian Rosen; Henning Schulzrinne Cc: modern@ietf.org Subject: RE: [Modern] Services I'm not so sure I agree that a TN should not have a fundamental association= with a single provider, but that's a policy issue. In the DNS an FQDN is d= elegated to a single party. I believe a registry architecture could - and t= he FCC wants it to - be able to accommodate a variety of potential policies= . IFF there were agreement on service definitions, then a registry could h= ave per-service delegation records. So I don't see that this is something t= hat could be or has to be decided now. -----Original Message----- From: Gorman, Pierce A [NTK] [mailto:Pierce.Gorman@sprint.com] Sent: Friday, October 17, 2014 9:49 AM To: Brian Rosen; Henning Schulzrinne Cc: modern@ietf.org; PFAUTZ, PENN L Subject: RE: [Modern] Services "... but I think the notion that there is one service provider per TN has l= ong past, and I would like to make sure that the TN is portable for all suc= h services that use it." HEAR HEAR!!! Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Brian Rosen Sent: October 17, 2014 7:51 AM To: Henning Schulzrinne Cc: modern@ietf.org; PFAUTZ, PENN L Subject: Re: [Modern] Services Yes, among many other services that use your phone number as an identifier.= I think the iMessage service is very interesting, because it really does= use the TN as the identifier. It has an association between a TN and an A= ppleId, which it then uses to extend who and how it contacts other users, b= ut that service is the "text" supplier for the device, and it may make use = of other services tied to the TN, such as the SMS service. I think, long term, that a service like voice (or video) really will be sep= arate from a service like text, and users will be free to choose whatever s= ervice provider they wish. I think the user interfaces for such services m= ay well be separate from the service providers. Of course bundles of servi= ces and user interfaces will continue to exist, but I think the notion that= there is one service provider per TN has long past, and I would like to ma= ke sure that the TN is portable for all such services that use it. Brian On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne wrote: > If they are both SIP services (say), I'm not sure how you'd distinguish t= hem (and make the call work without some voice IVR like "The number you hav= e reached has multiple services. Would you like to talk to 201 555 1234 via= AT&T, Vonage or Facebook?" > > As far as I can tell today, a single number today only has one provider. = Or are you talking about the case where I can use my SMS number as an Apple= iChat identifier, which then bypasses SMS? > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Thursday, October 16, 2014 4:43 PM > To: Henning Schulzrinne > Cc: PFAUTZ, PENN L; modern@ietf.org > Subject: Re: [Modern] Services > > Like it or not, we have OTT services using the same TN as the service pro= vider's services, even if there is overlap. That is, I suspect, exactly wh= at Penn was getting at. > > Brian _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Fri Oct 17 15:27:55 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787A21A1BAC for ; Fri, 17 Oct 2014 15:27:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 jw0XmajvyT7J for ; Fri, 17 Oct 2014 15:27:52 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id D856C1A1A1E for ; Fri, 17 Oct 2014 15:27:51 -0700 (PDT) Received: (qmail 24974 invoked by uid 0); 17 Oct 2014 22:27:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 17 Oct 2014 22:27:48 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 4U7i1p0091MNPNq01U7lwy; Fri, 17 Oct 2014 22:07:47 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=ll-iCDY8AAAA:8 a=izV7ms69AAAA:8 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=g8wsVloecptjInkJaK8A:9 a=7Vi4coG9g1IqCh2w:21 a=HVbuEazBjTCsZAxS:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 a=QtYQgBH6EwcA:10 a=2aF6lfeD-CsA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 a=-zy3ex45pM4A:10 a=Iw56Dgo-k0oA:10 a=NWVoK91CQyQA:10 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:CC:To:From:Subject:Date; bh=4wAeJCi3ORB7Fqh35eqAiwDS2gzZCUYth7qUoccGuoo=; b=iw1Yop2gPtctAyiUwiJGmRO6aLP34QHbz0c9XSCloMOMi65eeRBnem/YhbBNFx64T+qtirimSu+9odlQ+kZBsCZ85QDMnSzZJt5sZJcYm9T5YBvPFrGrxDptefPF9pby; Received: from [72.66.64.164] (port=57405 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XfFgU-0002Ht-TS; Fri, 17 Oct 2014 16:07:43 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Fri, 17 Oct 2014 18:07:38 -0400 From: Richard Shockey To: "Gorman, Pierce A [NTK]" , "PFAUTZ, PENN L" , Brian Rosen , Henning Schulzrinne Message-ID: Thread-Topic: [Modern] Services References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <808a3804e19f42ac8c3a630836c224cd@PLSWE13M08.ad.sprint.com> In-Reply-To: <808a3804e19f42ac8c3a630836c224cd@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/UQb--OCqK2TC2qyctnFl2TzwxiE Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:27:54 -0000 =8B Pierce ..understood. BTW some of you may recall I=B9ve written extensively on this in my filings with the FCC. Given the glide path on ICC/USF reform and PSTN transition full geographic number portability would be easy and purely a policy decision not a technical one. http://shockey.us/files/4813/9155/2471/FCC-Numbering.pdf Service portability is certainly doable. Though some providers might have issues. On 10/17/14, 3:46 PM, "Gorman, Pierce A [NTK]" wrote: >An FQDN is also not (very) portable. I like the idea that started with >portability many years ago that a TN can become the virtual property of >the user, rather than the provider. Its why non-geographic portability >appeals to me too. Not sure if inter-country portability will happen in >my lifetime (glad there's some roaming), but the idea that an integer can >be a universal language abstraction of how to contact me multiple >different ways is powerful. > >Note: Feel scared and need to disclaim that the opinions expressed herein >are my own, and should not be considered express or implied opinions of >Sprint. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > > >-----Original Message----- >From: PFAUTZ, PENN L [mailto:pp3129@att.com] >Sent: October 17, 2014 2:27 PM >To: Gorman, Pierce A [NTK]; Brian Rosen; Henning Schulzrinne >Cc: modern@ietf.org >Subject: RE: [Modern] Services > >I'm not so sure I agree that a TN should not have a fundamental >association with a single provider, but that's a policy issue. In the DNS >an FQDN is delegated to a single party. I believe a registry architecture >could - and the FCC wants it to - be able to accommodate a variety of >potential policies. IFF there were agreement on service definitions, >then a registry could have per-service delegation records. So I don't see >that this is something that could be or has to be decided now. > >-----Original Message----- >From: Gorman, Pierce A [NTK] [mailto:Pierce.Gorman@sprint.com] >Sent: Friday, October 17, 2014 9:49 AM >To: Brian Rosen; Henning Schulzrinne >Cc: modern@ietf.org; PFAUTZ, PENN L >Subject: RE: [Modern] Services > >"... but I think the notion that there is one service provider per TN has >long past, and I would like to make sure that the TN is portable for all >such services that use it." > >HEAR HEAR!!! > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Brian Rosen >Sent: October 17, 2014 7:51 AM >To: Henning Schulzrinne >Cc: modern@ietf.org; PFAUTZ, PENN L >Subject: Re: [Modern] Services > >Yes, among many other services that use your phone number as an >identifier. I think the iMessage service is very interesting, because >it really does use the TN as the identifier. It has an association >between a TN and an AppleId, which it then uses to extend who and how it >contacts other users, but that service is the "text" supplier for the >device, and it may make use of other services tied to the TN, such as the >SMS service. > >I think, long term, that a service like voice (or video) really will be >separate from a service like text, and users will be free to choose >whatever service provider they wish. I think the user interfaces for >such services may well be separate from the service providers. Of course >bundles of services and user interfaces will continue to exist, but I >think the notion that there is one service provider per TN has long past, >and I would like to make sure that the TN is portable for all such >services that use it. > >Brian > >On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne > wrote: > >> If they are both SIP services (say), I'm not sure how you'd distinguish >>them (and make the call work without some voice IVR like "The number you >>have reached has multiple services. Would you like to talk to 201 555 >>1234 via AT&T, Vonage or Facebook?" >> >> As far as I can tell today, a single number today only has one >>provider. Or are you talking about the case where I can use my SMS >>number as an Apple iChat identifier, which then bypasses SMS? >> >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Thursday, October 16, 2014 4:43 PM >> To: Henning Schulzrinne >> Cc: PFAUTZ, PENN L; modern@ietf.org >> Subject: Re: [Modern] Services >> >> Like it or not, we have OTT services using the same TN as the service >>provider's services, even if there is overlap. That is, I suspect, >>exactly what Penn was getting at. >> >> Brian > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Fri Oct 17 17:50:38 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEFC1A1B59 for ; Fri, 17 Oct 2014 17:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 zeRRIIAn9R7D for ; Fri, 17 Oct 2014 17:50:34 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1C66D1A1ACD for ; Fri, 17 Oct 2014 17:50:33 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [NTK]" , "PFAUTZ, PENN L" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAEmuAIAAEJRK Date: Sat, 18 Oct 2014 00:50:31 +0000 References: , <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com>, <808a3804e19f42ac8c3a630836c224cd@PLSWE13M08.ad.sprint.com> In-Reply-To: <808a3804e19f42ac8c3a630836c224cd@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/XK6umRWyf8j7N7ClF_WaI4_kitQ Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 00:50:36 -0000 By international portability, do you mean the ability of a non-US resident = to obtain a US phone number as, as you put it, virtual property or of a non= -US (Canadian) service provider to become available through a +1 number? Th= e latter seems relatively straightforward if the virtual owner can add his = own SIP URL, say, to the number record. (I'll ignore whether other carriers= would connect to that number, or should have to.)=0A= =0A= Germany, as far as I know, requires proof of residency before assigning VoI= P numbers through a provider.=0A= =0A= As far as I can tell, beyond the add-your-own SIP URL ability mentioned abo= ve, this wouldn't seem to affect the protocol or architecture design, just = the policies, which could presumably change. (They could conceivably differ= for 800 numbers, for example.)=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com]=0A= Sent: Friday, October 17, 2014 3:46 PM=0A= To: PFAUTZ, PENN L; Brian Rosen; Henning Schulzrinne=0A= Cc: modern@ietf.org=0A= Subject: RE: [Modern] Services=0A= =0A= An FQDN is also not (very) portable. I like the idea that started with por= tability many years ago that a TN can become the virtual property of the us= er, rather than the provider. Its why non-geographic portability appeals t= o me too. Not sure if inter-country portability will happen in my lifetime= (glad there's some roaming), but the idea that an integer can be a univers= al language abstraction of how to contact me multiple different ways is pow= erful.=0A= =0A= Note: Feel scared and need to disclaim that the opinions expressed herein a= re my own, and should not be considered express or implied opinions of Spri= nt.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Voice Architecture=0A= Core Planning/Sprint=0A= 913-439-4368 (Desk)=0A= =0A= =0A= -----Original Message-----=0A= From: PFAUTZ, PENN L [mailto:pp3129@att.com]=0A= Sent: October 17, 2014 2:27 PM=0A= To: Gorman, Pierce A [NTK]; Brian Rosen; Henning Schulzrinne=0A= Cc: modern@ietf.org=0A= Subject: RE: [Modern] Services=0A= =0A= I'm not so sure I agree that a TN should not have a fundamental association= with a single provider, but that's a policy issue. In the DNS an FQDN is d= elegated to a single party. I believe a registry architecture could - and t= he FCC wants it to - be able to accommodate a variety of potential policies= . IFF there were agreement on service definitions, then a registry could h= ave per-service delegation records. So I don't see that this is something t= hat could be or has to be decided now.=0A= =0A= -----Original Message-----=0A= From: Gorman, Pierce A [NTK] [mailto:Pierce.Gorman@sprint.com]=0A= Sent: Friday, October 17, 2014 9:49 AM=0A= To: Brian Rosen; Henning Schulzrinne=0A= Cc: modern@ietf.org; PFAUTZ, PENN L=0A= Subject: RE: [Modern] Services=0A= =0A= "... but I think the notion that there is one service provider per TN has l= ong past, and I would like to make sure that the TN is portable for all suc= h services that use it."=0A= =0A= HEAR HEAR!!!=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Voice Architecture=0A= Core Planning/Sprint=0A= 913-439-4368 (Desk)=0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Brian Rosen=0A= Sent: October 17, 2014 7:51 AM=0A= To: Henning Schulzrinne=0A= Cc: modern@ietf.org; PFAUTZ, PENN L=0A= Subject: Re: [Modern] Services=0A= =0A= Yes, among many other services that use your phone number as an identifier.= I think the iMessage service is very interesting, because it really does= use the TN as the identifier. It has an association between a TN and an A= ppleId, which it then uses to extend who and how it contacts other users, b= ut that service is the "text" supplier for the device, and it may make use = of other services tied to the TN, such as the SMS service.=0A= =0A= I think, long term, that a service like voice (or video) really will be sep= arate from a service like text, and users will be free to choose whatever s= ervice provider they wish. I think the user interfaces for such services m= ay well be separate from the service providers. Of course bundles of servi= ces and user interfaces will continue to exist, but I think the notion that= there is one service provider per TN has long past, and I would like to ma= ke sure that the TN is portable for all such services that use it.=0A= =0A= Brian=0A= =0A= On Oct 16, 2014, at 8:13 PM, Henning Schulzrinne wrote:=0A= =0A= > If they are both SIP services (say), I'm not sure how you'd distinguish t= hem (and make the call work without some voice IVR like "The number you hav= e reached has multiple services. Would you like to talk to 201 555 1234 via= AT&T, Vonage or Facebook?"=0A= >=0A= > As far as I can tell today, a single number today only has one provider. = Or are you talking about the case where I can use my SMS number as an Apple= iChat identifier, which then bypasses SMS?=0A= >=0A= > ________________________________________=0A= > From: Brian Rosen [br@brianrosen.net]=0A= > Sent: Thursday, October 16, 2014 4:43 PM=0A= > To: Henning Schulzrinne=0A= > Cc: PFAUTZ, PENN L; modern@ietf.org=0A= > Subject: Re: [Modern] Services=0A= >=0A= > Like it or not, we have OTT services using the same TN as the service pro= vider's services, even if there is overlap. That is, I suspect, exactly wh= at Penn was getting at.=0A= >=0A= > Brian=0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= =0A= From nobody Fri Oct 17 17:56:52 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A06F1A0008 for ; Fri, 17 Oct 2014 17:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Ie1M5nLb3rQR for ; Fri, 17 Oct 2014 17:56:49 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2971A0006 for ; Fri, 17 Oct 2014 17:56:49 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "PFAUTZ, PENN L" , "Gorman, Pierce A [NTK]" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixQ== Date: Sat, 18 Oct 2014 00:56:48 +0000 References: , , <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/AexT5OjyLjFDDIGtSUpxZjBp6Vg Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 00:56:51 -0000 You can always add a layer of indirection via DNS NAPTR. The only indirect = decision is whether the number record may contain a single URL, a domain re= cord that can then add service types as in ENUM, or a list of these, with s= ervice identifiers. =0A= =0A= If we're trying to compile requirements, we probably do have to decide that= level of detail.=0A= =0A= In DNS, a domain belongs to one party, but it's easy to point the MX record= to one destination, and the other records to another. With SRV, you get pr= otocol-specific redirection.=0A= =0A= My mental model is that assignment of a number is roughly equivalent to ass= ignment of a DNS name in that sense (leaving aside who can be assigned the = record; even if that's only a carrier, a separate policy decision could man= date the ability to carry additional provider pointers, for example). Does = that model work?=0A= =0A= ________________________________________=0A= From: PFAUTZ, PENN L [pp3129@att.com]=0A= Sent: Friday, October 17, 2014 3:26 PM=0A= To: Gorman, Pierce A [NTK]; Brian Rosen; Henning Schulzrinne=0A= Cc: modern@ietf.org=0A= Subject: RE: [Modern] Services=0A= =0A= I'm not so sure I agree that a TN should not have a fundamental association= with a single provider, but that's a policy issue. In the DNS an FQDN is d= elegated to a single party. I believe a registry architecture could - and t= he FCC wants it to - be able to accommodate a variety of potential policies= . IFF there were agreement on service definitions, then a registry could h= ave per-service delegation records. So I don't see that this is something t= hat could be or has to be decided now.=0A= From nobody Fri Oct 17 17:59:02 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105911A000B for ; Fri, 17 Oct 2014 17:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Nz4cVwVrbFPr for ; Fri, 17 Oct 2014 17:59:01 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 282AE1A0006 for ; Fri, 17 Oct 2014 17:59:01 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [NTK]" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAUClUIAAXvMy Date: Sat, 18 Oct 2014 00:58:59 +0000 References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/n_ztRgovIcQGxS7GL_XunNuGjlM Cc: "modern@ietf.org" , "PFAUTZ, PENN L" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 00:59:02 -0000 This sounds similar to the NAPTR/SRV ordering, where the destination (domai= n owner) rank-orders the choices.=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com]=0A= Sent: Friday, October 17, 2014 3:21 PM=0A= To: Henning Schulzrinne; Brian Rosen=0A= Cc: modern@ietf.org; PFAUTZ, PENN L=0A= Subject: RE: [Modern] Services=0A= =0A= IVR wouild be one way. The app could also assume that termination in a lik= e app/provider if available, or one or more preferences settings. E.g., us= e least-cost app/provider.=0A= =0A= Best regards,=0A= =0A= From nobody Sat Oct 18 17:31:16 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A1B1A1A5B for ; Sat, 18 Oct 2014 17:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 bKSeFpcNG5qv for ; Sat, 18 Oct 2014 17:31:13 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 38EA91A0461 for ; Sat, 18 Oct 2014 17:31:13 -0700 (PDT) Received: (qmail 1340 invoked by uid 0); 19 Oct 2014 00:31:10 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 19 Oct 2014 00:31:10 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 4uWy1p00U1MNPNq01uX1SJ; Sun, 19 Oct 2014 00:31:09 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=XMwjShkacBE0vja6nw0A:9 a=lKNOSF09aTGghydU:21 a=T30VULhNukzIF8Rk:21 a=wPNLvfGTeEIA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 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:CC:To:From:Subject:Date; bh=B0rFpb5KLZbWZkf4kvgRA/i2mgrF++tSK7+rtZAeKfM=; b=QWLaVbkVHKl/SNPUYXzA3WjOu8CaLYap9Paodc4tvkB+PkvLECrlraniQMBNheE27Bm62l4QXqGHyp9Kb8lIijvQVrruZhhTCEvqhoW/0zSMqY9RS7OgOECOZ7dTR8sj; Received: from [72.66.64.164] (port=49319 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XfeOh-0007tB-5S; Sat, 18 Oct 2014 18:30:59 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Sat, 18 Oct 2014 20:30:53 -0400 From: Richard Shockey To: Henning Schulzrinne , "PFAUTZ, PENN L" , "Gorman, Pierce A [NTK]" , Brian Rosen Message-ID: Thread-Topic: [Modern] Services References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/R_TLjDxV7s4cbKPzQyjmgAAI4tg Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 00:31:14 -0000 In general I=B9d agree that a phone number is essentially a domain in the classic theory of the abstraction of naming and addressing. That domain should be consumer enterprise centric and carriers will ultimately IMHO manage that service but I can also see the classic resistance of service providers to the larger issue of number administration by consumers etc. We=B9ve seen number administration become a classic barrier to entry for competitors. I can site cases if anyone is interested. But the larger thrust here is something more interesting. What is the real alternative to DNS for different classes of names outside the ICANN model. Istnt that what we are talking about? We accept and create a model of resolution of one class of names E.164 totally outside the ICANN model of administration. NGN ENUM not using DNS preserving the traditional rights of nation states to administer their portions of the numbering plan? I=B9m just thinking.=20 On 10/17/14, 8:56 PM, "Henning Schulzrinne" wrote: >You can always add a layer of indirection via DNS NAPTR. The only >indirect decision is whether the number record may contain a single URL, >a domain record that can then add service types as in ENUM, or a list of >these, with service identifiers. > >If we're trying to compile requirements, we probably do have to decide >that level of detail. > >In DNS, a domain belongs to one party, but it's easy to point the MX >record to one destination, and the other records to another. With SRV, >you get protocol-specific redirection. > >My mental model is that assignment of a number is roughly equivalent to >assignment of a DNS name in that sense (leaving aside who can be assigned >the record; even if that's only a carrier, a separate policy decision >could mandate the ability to carry additional provider pointers, for >example). Does that model work? > >________________________________________ >From: PFAUTZ, PENN L [pp3129@att.com] >Sent: Friday, October 17, 2014 3:26 PM >To: Gorman, Pierce A [NTK]; Brian Rosen; Henning Schulzrinne >Cc: modern@ietf.org >Subject: RE: [Modern] Services > >I'm not so sure I agree that a TN should not have a fundamental >association with a single provider, but that's a policy issue. In the DNS >an FQDN is delegated to a single party. I believe a registry architecture >could - and the FCC wants it to - be able to accommodate a variety of >potential policies. IFF there were agreement on service definitions, >then a registry could have per-service delegation records. So I don't see >that this is something that could be or has to be decided now. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Sun Oct 19 16:04:45 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6F1A0673 for ; Sun, 19 Oct 2014 16:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 eg58CFU6aYVH for ; Sun, 19 Oct 2014 16:04:43 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401921A066C for ; Sun, 19 Oct 2014 16:04:43 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id b8344445.2b3b40c0d940.7527042.00-2439.21175797.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 19 Oct 2014 23:04:43 +0000 (UTC) X-MXL-Hash: 5444438b367d3e11-5954f5f69c21251e754ccc04da930481d41a69d5 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 78344445.0.7527032.00-2367.21175771.nbfkord-smmo07.seg.att.com (envelope-from ); Sun, 19 Oct 2014 23:04:42 +0000 (UTC) X-MXL-Hash: 5444438a79726e35-592aa5c35c2ba8f742d76da4227fc333fce1f5c1 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 s9JN4dFO007455; Sun, 19 Oct 2014 19:04:39 -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 s9JN4OhS007348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Oct 2014 19:04:27 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 19 Oct 2014 23:04:11 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 19:04:11 -0400 From: "PFAUTZ, PENN L" To: Henning Schulzrinne , "Gorman, Pierce A [NTK]" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYADByog Date: Sun, 19 Oct 2014 23:04:10 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D60574190E@MISOUT7MSGUSRDD.ITServices.sbc.com> References: , , <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.45.111] 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-AnalysisOut: [v=2.0 cv=ae/Wa2Ut c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=4uxBuk8I3VoA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=EC0AiP3QK6-0axXqz2MA:9 a=CjuIK1q_8ugA:10 a=lZB815d] X-AnalysisOut: [zVvQA:10 a=Hz7IrDYlS0cA:10 a=AahNpHFhV_mwMkyj:21 a=yw7BxJn] X-AnalysisOut: [UJEjYhaqz:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/goLL1YC5UU8XIQ2OoYBgCqMuWBo Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 23:04:44 -0000 Yes. I think that model can encompass the important set of possible policie= s -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Friday, October 17, 2014 8:57 PM To: PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rosen Cc: modern@ietf.org Subject: RE: [Modern] Services You can always add a layer of indirection via DNS NAPTR. The only indirect = decision is whether the number record may contain a single URL, a domain re= cord that can then add service types as in ENUM, or a list of these, with s= ervice identifiers.=20 If we're trying to compile requirements, we probably do have to decide that= level of detail. In DNS, a domain belongs to one party, but it's easy to point the MX record= to one destination, and the other records to another. With SRV, you get pr= otocol-specific redirection. My mental model is that assignment of a number is roughly equivalent to ass= ignment of a DNS name in that sense (leaving aside who can be assigned the = record; even if that's only a carrier, a separate policy decision could man= date the ability to carry additional provider pointers, for example). Does = that model work? ________________________________________ From: PFAUTZ, PENN L [pp3129@att.com] Sent: Friday, October 17, 2014 3:26 PM To: Gorman, Pierce A [NTK]; Brian Rosen; Henning Schulzrinne Cc: modern@ietf.org Subject: RE: [Modern] Services I'm not so sure I agree that a TN should not have a fundamental association= with a single provider, but that's a policy issue. In the DNS an FQDN is d= elegated to a single party. I believe a registry architecture could - and t= he FCC wants it to - be able to accommodate a variety of potential policies= . IFF there were agreement on service definitions, then a registry could h= ave per-service delegation records. So I don't see that this is something t= hat could be or has to be decided now. From nobody Sun Oct 19 17:38:41 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E421A1A65 for ; Sun, 19 Oct 2014 17:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aeDxmyJyttUI for ; Sun, 19 Oct 2014 17:38:37 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id B10BD1A1A64 for ; Sun, 19 Oct 2014 17:38:37 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , "PFAUTZ, PENN L" , "Gorman, Pierce A [NTK]" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfs= Date: Mon, 20 Oct 2014 00:38:35 +0000 References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/o3XRaYB6Jv-Eh-sJbs4TQYLbKSc Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 00:38:39 -0000 This isn't *that* new, although obviously at a new scale. For example, ther= e are many domain-specific URN schemes (e.g., DOIs for science publications= ) that are assigned outside ICANN control, but interact with DNS.=0A= =0A= We already have very basic mapping from numbers to domain names or IP addre= sses in the existing databases (and most certainly in the VRS numbering dat= abase), so this is not fundamentally new even for phone numbers.=0A= =0A= Besides the who-won't-like-it question, we already have a number space not = managed by carriers, namely 800#. They illustrate to some extent that this = can work technically, but preventing hoarding may require more scalable mec= hanisms than relying on kicking misbehaving entities out of the club.=0A= =0A= Thus, as a strawman, I could picture that the number record returned by a q= uery returns (optionally) a domain name, resolved via DNS SRV or NAPTR as t= he next step. This allows various combinations of managed-by-carrier and ma= naged-by-end user, depending on who gets to manage the DNS entry and who ge= ts to manage the number record. This then becomes a policy knob, beyond the= MODERN discussion.=0A= =0A= ________________________________________=0A= From: Richard Shockey [richard@shockey.us]=0A= Sent: Saturday, October 18, 2014 8:30 PM=0A= To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rose= n=0A= Cc: modern@ietf.org=0A= Subject: Re: [Modern] Services=0A= =0A= In general I=B9d agree that a phone number is essentially a domain in the= =0A= classic theory of the abstraction of naming and addressing. That domain=0A= should be consumer enterprise centric and carriers will ultimately IMHO=0A= manage that service but I can also see the classic resistance of service=0A= providers to the larger issue of number administration by consumers etc.=0A= =0A= We=B9ve seen number administration become a classic barrier to entry for=0A= competitors. I can site cases if anyone is interested.=0A= =0A= But the larger thrust here is something more interesting. What is the=0A= real alternative to DNS for different classes of names outside the ICANN=0A= model. Istnt that what we are talking about? We accept and create a=0A= model of resolution of one class of names E.164 totally outside the ICANN= =0A= model of administration.=0A= =0A= NGN ENUM not using DNS preserving the traditional rights of nation states= =0A= to administer their portions of the numbering plan?=0A= =0A= I=B9m just thinking.=0A= =0A= From nobody Mon Oct 20 06:51:46 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C791A877B for ; Mon, 20 Oct 2014 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 WBZ3DcBPkHRS for ; Mon, 20 Oct 2014 06:51:41 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6661A877F for ; Mon, 20 Oct 2014 06:51:27 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id j107so3477603qga.16 for ; Mon, 20 Oct 2014 06:51:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=FqTBKMWn10OPNDu/NvvN5wkrFOWvAhQ/JKOA5vPOzTk=; b=ZHjno394GOvFAu3oFFLxPVQhU7uNi7DWYDwsMS35oQikADa/2XkWnycYT6DI1w7uzI 5KhfHB/VTR5SLM6a+yf4QfrY8I/OnYJxdhpFLbW0RLwPhLKgpNmQQ9NZHuLUKgaWuptm ylOsFEydPXdxbrPjs6ecojqD0b6iQcVtH0ZotBy7saDqW9AC3KfqtLLtNXi/r/zz+Y3M NHXZBLz3IF4/6erQqBKnuCqZupkJVVr0wUOlabp/fsVoqWIyOgixm7BA3WcDCTSG8q2f Dk1jKM0RsDcRcBD/3VaX/E6HFXQV/JWHb0ncNPBaVKG+feySihlUkCxpq1HcTJGj3jwP I4mA== X-Gm-Message-State: ALoCoQl6ahCrbpta9LtE+lvAk0kTcBQKTtYEl8bpOlIidQGZG2hrgW6D5F9leR8ZPMvDHQYR1uGH X-Received: by 10.224.61.7 with SMTP id r7mr36592727qah.9.1413813086364; Mon, 20 Oct 2014 06:51:26 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id i97sm3160819qge.49.2014.10.20.06.51.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 06:51:25 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: Date: Mon, 20 Oct 2014 09:51:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/zbBCufhz0IUWYCXVNw01TNoQR_8 Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 13:51:44 -0000 I really would like to get away from DNS entirely. We can reuse = concepts, but I think DNS is not the appropriate way to get anything to = do with E.164s. ENUM was a mistake, and one of the mistakes was using DNS. It=92s not = the appropriate query mechanism, and it has a golden root problem. I = remember well the DNS guys questioning whether DNS was the right = protocol when we started ENUM. We were so sure it was. It was a = mistake then, and it is now. Let=92s learn from that and stay away from DNS. =20 We need a query with TN and service that returns either some form of = service provider id/service URL and/or some form of route. I personally = think that it would be best to keep route separate from service provider = id/URL because I do think the user controls that part of the record = while the SP controls the route. Brian > On Oct 19, 2014, at 8:38 PM, Henning Schulzrinne = wrote: >=20 > This isn't *that* new, although obviously at a new scale. For example, = there are many domain-specific URN schemes (e.g., DOIs for science = publications) that are assigned outside ICANN control, but interact with = DNS. >=20 > We already have very basic mapping from numbers to domain names or IP = addresses in the existing databases (and most certainly in the VRS = numbering database), so this is not fundamentally new even for phone = numbers. >=20 > Besides the who-won't-like-it question, we already have a number space = not managed by carriers, namely 800#. They illustrate to some extent = that this can work technically, but preventing hoarding may require more = scalable mechanisms than relying on kicking misbehaving entities out of = the club. >=20 > Thus, as a strawman, I could picture that the number record returned = by a query returns (optionally) a domain name, resolved via DNS SRV or = NAPTR as the next step. This allows various combinations of = managed-by-carrier and managed-by-end user, depending on who gets to = manage the DNS entry and who gets to manage the number record. This then = becomes a policy knob, beyond the MODERN discussion. >=20 > ________________________________________ > From: Richard Shockey [richard@shockey.us] > Sent: Saturday, October 18, 2014 8:30 PM > To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian = Rosen > Cc: modern@ietf.org > Subject: Re: [Modern] Services >=20 > In general I=B9d agree that a phone number is essentially a domain in = the > classic theory of the abstraction of naming and addressing. That = domain > should be consumer enterprise centric and carriers will ultimately = IMHO > manage that service but I can also see the classic resistance of = service > providers to the larger issue of number administration by consumers = etc. >=20 > We=B9ve seen number administration become a classic barrier to entry = for > competitors. I can site cases if anyone is interested. >=20 > But the larger thrust here is something more interesting. What is the > real alternative to DNS for different classes of names outside the = ICANN > model. Istnt that what we are talking about? We accept and create a > model of resolution of one class of names E.164 totally outside the = ICANN > model of administration. >=20 > NGN ENUM not using DNS preserving the traditional rights of nation = states > to administer their portions of the numbering plan? >=20 > I=B9m just thinking. >=20 From nobody Mon Oct 20 07:01:15 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470051A882C for ; Mon, 20 Oct 2014 07:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 tZXvWyhOX3nz for ; Mon, 20 Oct 2014 07:01:00 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1C51A882E for ; Mon, 20 Oct 2014 06:57:53 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKe Date: Mon, 20 Oct 2014 13:57:51 +0000 References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> , <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> In-Reply-To: <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/EmxNNQ3mXy8MvQ7U5zEga0gIZhM Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:01:07 -0000 I suspect we're talking past each other. I'm not advocating a "golden root"= or anything that looks like ENUM number-based mapping. As a strawman, cons= ider a JSON response within the MODERN context to a query for a phone numbe= r, returning for you=0A= =0A= "media": "myphone.brianrosen.net"=0A= =0A= with myphone.brianrosen.net=0A= =0A= resolving to=0A= =0A= _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.=0A= =0A= =0A= I assume we don't want to put IP addresses directly into the response, so D= NS enters the picture at some point.=0A= =0A= The alternative is to use the SRV or NAPTR service field (here, _sip._tcp) = directly in the MODERN response. I can see advantages to both.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Brian Rosen [br@brianrosen.net]=0A= Sent: Monday, October 20, 2014 9:51 AM=0A= To: Henning Schulzrinne=0A= Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g=0A= Subject: Re: [Modern] Services=0A= =0A= I really would like to get away from DNS entirely. We can reuse concepts, = but I think DNS is not the appropriate way to get anything to do with E.164= s.=0A= ENUM was a mistake, and one of the mistakes was using DNS. It=92s not the = appropriate query mechanism, and it has a golden root problem. I remember = well the DNS guys questioning whether DNS was the right protocol when we st= arted ENUM. We were so sure it was. It was a mistake then, and it is now.= =0A= =0A= Let=92s learn from that and stay away from DNS.=0A= =0A= We need a query with TN and service that returns either some form of servic= e provider id/service URL and/or some form of route. I personally think th= at it would be best to keep route separate from service provider id/URL bec= ause I do think the user controls that part of the record while the SP cont= rols the route.=0A= =0A= Brian= From nobody Mon Oct 20 07:31:25 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2C1A88EE for ; Mon, 20 Oct 2014 07:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 phes-9Fod-iQ for ; Mon, 20 Oct 2014 07:31:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9731A88ED for ; Mon, 20 Oct 2014 07:11:10 -0700 (PDT) Received: from BN1BFFO11FD039.protection.gbl (10.58.144.33) by BN1BFFO11HUB037.protection.gbl (10.58.144.184) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Mon, 20 Oct 2014 14:10:46 +0000 Received: from plsasdm1.corp.sprint.com (144.230.168.25) by BN1BFFO11FD039.mail.protection.outlook.com (10.58.144.102) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Mon, 20 Oct 2014 14:10:46 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9KEAgr1017080 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 09:10:45 -0500 Received: from PLSWE13M08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9KEAeuO023885 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Oct 2014 09:10:44 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 20 Oct 2014 09:10:42 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Mon, 20 Oct 2014 09:10:42 -0500 From: "Gorman, Pierce A [NTK]" To: Henning Schulzrinne , Richard Shockey , "PFAUTZ, PENN L" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYAB4IaAgAGUfICAAIgacA== Date: Mon, 20 Oct 2014 14:10:41 +0000 Message-ID: <043c13e2db7140abba470aa8bc23da30@PLSWE13M08.ad.sprint.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.168.25; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377454003)(13464003)(199003)(46102003)(80022003)(21056001)(15202345003)(50466002)(120916001)(44976005)(19580405001)(87936001)(6806004)(2656002)(15975445006)(19580395003)(77096002)(99396003)(64706001)(20776003)(47776003)(54356999)(26826002)(76176999)(50986999)(86362001)(85852003)(92566001)(108616004)(85306004)(93886004)(95666004)(33646002)(31966008)(76482002)(4396001)(106466001)(106116001)(23756003)(107046002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB037; H:plsasdm1.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpls1.sprint.com; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB037; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 03706074BC Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.25 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.25; helo=plsasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.25) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/CBU_SwMyqj-6xZ0NcP0m-cgYFcw Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:31:22 -0000 As mentioned before, classical DNS ENUM does not work well for numerous voi= ce call routing requirements. There may be other applications which would = also find the source-information limitations of classical ENUM TN to URI re= solution process cumbersome or inadequate. The "EDNS Option Code for SIP and PSTN Source Reference Info" (http://tool= s.ietf.org/html/draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03) provid= es one way to address the source-information shortcoming of classical ENUM = TN, but as Richard Shockey put it back in August, "Its duct tape and bailin= g wire but it works." I certainly agree with the "duct tape and bailing wi= re" aspects. My experience has been that SRV load distribution and failure-recovery impl= ementations based on weight and priority are not always straight forward. = Is a SIP 503 a server failure that requires a different choice based on pri= ority, or does it require a 6xx? TTL is also not always respected. Assumi= ng UDP is used for large-scale query/response processing, what happens if/w= hen large quantities of NAPTR RR responses are larger than what fits in the= (extended?) UDP payload limit and requires TCP re-tries? DNS NAPTR, OPT, SRV, A/AAAA is just barely adequate for most featureless lo= cal and long-distance voice call routing requirements but inadequate otherw= ise. E.g., toll-free. I am not saying we should abandon DNS ENUM, but I am saying we should be op= en to considering something other than DNS for more complex service/applica= tion session routing requirements. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: October 19, 2014 7:39 PM To: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rosen Cc: modern@ietf.org Subject: RE: [Modern] Services This isn't *that* new, although obviously at a new scale. For example, ther= e are many domain-specific URN schemes (e.g., DOIs for science publications= ) that are assigned outside ICANN control, but interact with DNS. We already have very basic mapping from numbers to domain names or IP addre= sses in the existing databases (and most certainly in the VRS numbering dat= abase), so this is not fundamentally new even for phone numbers. Besides the who-won't-like-it question, we already have a number space not = managed by carriers, namely 800#. They illustrate to some extent that this = can work technically, but preventing hoarding may require more scalable mec= hanisms than relying on kicking misbehaving entities out of the club. Thus, as a strawman, I could picture that the number record returned by a q= uery returns (optionally) a domain name, resolved via DNS SRV or NAPTR as t= he next step. This allows various combinations of managed-by-carrier and ma= naged-by-end user, depending on who gets to manage the DNS entry and who ge= ts to manage the number record. This then becomes a policy knob, beyond the= MODERN discussion. ________________________________________ From: Richard Shockey [richard@shockey.us] Sent: Saturday, October 18, 2014 8:30 PM To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rose= n Cc: modern@ietf.org Subject: Re: [Modern] Services In general I=B9d agree that a phone number is essentially a domain in the c= lassic theory of the abstraction of naming and addressing. That domain sho= uld be consumer enterprise centric and carriers will ultimately IMHO manage= that service but I can also see the classic resistance of service provider= s to the larger issue of number administration by consumers etc. We=B9ve seen number administration become a classic barrier to entry for co= mpetitors. I can site cases if anyone is interested. But the larger thrust here is something more interesting. What is the real= alternative to DNS for different classes of names outside the ICANN model. Istnt that what we are talking about? We accept and create a model of resolution of one class of names E.164 totally outside the ICANN m= odel of administration. NGN ENUM not using DNS preserving the traditional rights of nation states t= o administer their portions of the numbering plan? I=B9m just thinking. ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Oct 20 07:32:12 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F201AC3CA for ; Mon, 20 Oct 2014 07:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URI_TRY_3LD=0.001] autolearn=ham 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 zb99iyCZzta2 for ; Mon, 20 Oct 2014 07:32:08 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A58F1A9039 for ; Mon, 20 Oct 2014 07:11:40 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so3726869qcw.31 for ; Mon, 20 Oct 2014 07:11:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=V1xZWnmzD8iKVnDETzgwOEOKzXYVTB9xS75BY2vJA3s=; b=Df2/JCFyjpMzy8ndNTIbvzRHkR5wfeN15Yr4CaoqccyZc/MEjkZpHsgSA7kRiqvtr1 qfhW9XMm9UVQQc8vMTFvujqTBRnPmlNFm+MXiwoiDn7RYyCXT85WUjtqdHTyHUUGdSHC 1TrVWx45InQ9vn0YmQCQSaMGgUHy4VHZ0q0u1hq7WewSfk2nh54QMogJjwfgkso9YDNP C3PwC9pjfokiUaEK9S5mLq6VVGCQETuFBqQcnselq70UW0F216Rz/Mxb6/IYXjNQQlbR qjLZ92psI6Dq3mmdplpbuGts0uEFKisaurHtSIIqoieHx9MEwFkf0I2+1nimL0ht7Uji zK/w== X-Gm-Message-State: ALoCoQki4i9O2mRoyGqZ7my3x/BFjkCaCXYwfXYIl4+SU9eQdC3RIPdXq+fX6PXf+6dfX1/d5sSn X-Received: by 10.224.4.72 with SMTP id 8mr16488503qaq.4.1413814299400; Mon, 20 Oct 2014 07:11:39 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id a9sm7973778qgf.7.2014.10.20.07.11.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 07:11:38 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: Date: Mon, 20 Oct 2014 10:11:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <, <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/5AWuL0x4xBRm46NVPLUTrO3hHmk Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:32:11 -0000 Okay, perhaps we are. I think =93media=94 is not a good service, but we=92ll see. I think = it=92s more like voice/video/text/event. They can always all have the = same response. I think that using SRV is not a good enough routing protocol, although = allowing it would be fine with me. SRV, like lots of things, does not = properly consider the source, nor the location, both requirements. It might be okay to have a two step route where the first step resolves = to a rendezvous for negotiation of the signaling and media interchange = points, but I would think that would be the result of the first =93modern=94= query =3D it returns a URI where you negotiate interchange. The second = step would have some notion of location and source identity and returns = route. =20 Brian > On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne = wrote: >=20 > I suspect we're talking past each other. I'm not advocating a "golden = root" or anything that looks like ENUM number-based mapping. As a = strawman, consider a JSON response within the MODERN context to a query = for a phone number, returning for you >=20 > "media": "myphone.brianrosen.net" >=20 > with myphone.brianrosen.net >=20 > resolving to >=20 > _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >=20 >=20 > I assume we don't want to put IP addresses directly into the response, = so DNS enters the picture at some point. >=20 > The alternative is to use the SRV or NAPTR service field (here, = _sip._tcp) directly in the MODERN response. I can see advantages to = both. >=20 > Henning >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 9:51 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = modern@ietf.org > Subject: Re: [Modern] Services >=20 > I really would like to get away from DNS entirely. We can reuse = concepts, but I think DNS is not the appropriate way to get anything to = do with E.164s. > ENUM was a mistake, and one of the mistakes was using DNS. It=92s not = the appropriate query mechanism, and it has a golden root problem. I = remember well the DNS guys questioning whether DNS was the right = protocol when we started ENUM. We were so sure it was. It was a = mistake then, and it is now. >=20 > Let=92s learn from that and stay away from DNS. >=20 > We need a query with TN and service that returns either some form of = service provider id/service URL and/or some form of route. I personally = think that it would be best to keep route separate from service provider = id/URL because I do think the user controls that part of the record = while the SP controls the route. >=20 > Brian From nobody Mon Oct 20 07:40:41 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD62E1A9077 for ; Mon, 20 Oct 2014 07:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 doHfBI2PbLwq for ; Mon, 20 Oct 2014 07:40:25 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391DD1A870B for ; Mon, 20 Oct 2014 07:18:37 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id i13so3328804qae.41 for ; Mon, 20 Oct 2014 07:18:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=2BzXMC7mhF/xiL4oVFjXjLapaFcxgn0zaGm4NrUJ7AY=; b=YMRfoZoxkqgJcjRLowyIynFioq0UKPhdDgjmk/KdmTbEJ1XpRBOWZnksmh9qXpfyrB hfDSzPoXbnFxmzx17XAmgY1a3tUoAjMGPoTaCRxgzK/vkybrgMLaJVc4bivKwdDutGGm 4LebTdC0ADq1QkeeggKcqav/e6qhOIUd9aQbXCS3JL9HBd0q02QuqxSiDZCZvxzzS70p cmW7Ao27lA53pCsAJOYHgXPPZ2PN+lT3UnxQpKHm7YlV1kKS3iFd/nDZyxPTujelKoEa KMiwMg8q8C/neCN6wCILqBIPN7X2bIP5xp+vBQqzhx0gnLz3no+UCkHLJvw5PKpNljz8 JaAQ== X-Gm-Message-State: ALoCoQmR40viIAf4B1AwZn2wxv2TUl19NT1YBTAlL3BRtvr/TFKsZec+iz/IvXKBJIiJWi/PvQZA X-Received: by 10.224.64.71 with SMTP id d7mr35683190qai.16.1413814715432; Mon, 20 Oct 2014 07:18:35 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id s10sm8001005qac.14.2014.10.20.07.18.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 07:18:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: <38726EDA2109264987B45E29E758C4D605741C6A@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Mon, 20 Oct 2014 10:18:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A5A8D56-1C89-4F9C-ACBD-6FB370CA019E@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741C6A@MISOUT7MSGUSRDD.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/MS7kFwR-0ye3fTKGjTgmTVOPFPA Cc: "modern@ietf.org" , Richard Shockey , "Gorman, Pierce A \[NTK\]" , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:40:38 -0000 Agree. I think we=92re thinking REST/json Brian > On Oct 20, 2014, at 10:16 AM, PFAUTZ, PENN L wrote: >=20 > I don't want to rehash the history of ENUM and I recognize there are = some tasks it doesn't do well. I will, however, be skeptical of any = one-off protocol for managing E.164 public user identities. I would = expect that, like ENUM, whatever we come up with will be built on some = more general protocol. I would also like to see some technical = commonality with the management of other types of PUIDs. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, October 20, 2014 9:51 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = modern@ietf.org > Subject: Re: [Modern] Services >=20 > I really would like to get away from DNS entirely. We can reuse = concepts, but I think DNS is not the appropriate way to get anything to = do with E.164s. > ENUM was a mistake, and one of the mistakes was using DNS. It's not = the appropriate query mechanism, and it has a golden root problem. I = remember well the DNS guys questioning whether DNS was the right = protocol when we started ENUM. We were so sure it was. It was a = mistake then, and it is now. >=20 > Let's learn from that and stay away from DNS. =20 >=20 > We need a query with TN and service that returns either some form of = service provider id/service URL and/or some form of route. I personally = think that it would be best to keep route separate from service provider = id/URL because I do think the user controls that part of the record = while the SP controls the route. >=20 > Brian >=20 >> On Oct 19, 2014, at 8:38 PM, Henning Schulzrinne = wrote: >>=20 >> This isn't *that* new, although obviously at a new scale. For = example, there are many domain-specific URN schemes (e.g., DOIs for = science publications) that are assigned outside ICANN control, but = interact with DNS. >>=20 >> We already have very basic mapping from numbers to domain names or IP = addresses in the existing databases (and most certainly in the VRS = numbering database), so this is not fundamentally new even for phone = numbers. >>=20 >> Besides the who-won't-like-it question, we already have a number = space not managed by carriers, namely 800#. They illustrate to some = extent that this can work technically, but preventing hoarding may = require more scalable mechanisms than relying on kicking misbehaving = entities out of the club. >>=20 >> Thus, as a strawman, I could picture that the number record returned = by a query returns (optionally) a domain name, resolved via DNS SRV or = NAPTR as the next step. This allows various combinations of = managed-by-carrier and managed-by-end user, depending on who gets to = manage the DNS entry and who gets to manage the number record. This then = becomes a policy knob, beyond the MODERN discussion. >>=20 >> ________________________________________ >> From: Richard Shockey [richard@shockey.us] >> Sent: Saturday, October 18, 2014 8:30 PM >> To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = Brian Rosen >> Cc: modern@ietf.org >> Subject: Re: [Modern] Services >>=20 >> In general I=B9d agree that a phone number is essentially a domain in = the >> classic theory of the abstraction of naming and addressing. That = domain >> should be consumer enterprise centric and carriers will ultimately = IMHO >> manage that service but I can also see the classic resistance of = service >> providers to the larger issue of number administration by consumers = etc. >>=20 >> We=B9ve seen number administration become a classic barrier to entry = for >> competitors. I can site cases if anyone is interested. >>=20 >> But the larger thrust here is something more interesting. What is = the >> real alternative to DNS for different classes of names outside the = ICANN >> model. Istnt that what we are talking about? We accept and create = a >> model of resolution of one class of names E.164 totally outside the = ICANN >> model of administration. >>=20 >> NGN ENUM not using DNS preserving the traditional rights of nation = states >> to administer their portions of the numbering plan? >>=20 >> I=B9m just thinking. >>=20 >=20 From nobody Mon Oct 20 07:42:58 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B91F1A89B4 for ; Mon, 20 Oct 2014 07:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rE-_1lDmyH7f for ; Mon, 20 Oct 2014 07:42:51 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E0A1A9110 for ; Mon, 20 Oct 2014 07:19:59 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id f0a15445.2b7ae5441940.655154.00-2496.1796532.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 20 Oct 2014 14:19:59 +0000 (UTC) X-MXL-Hash: 54451a0f73c60683-ede07888f72eea39bda3fcef76d8008acdb4c166 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id b6915445.0.652589.00-2310.1789168.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 20 Oct 2014 14:17:17 +0000 (UTC) X-MXL-Hash: 5445196d637f3f4f-68fc723341ace03074747d8272846d81f4726564 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 s9KEHEDw027556; Mon, 20 Oct 2014 10:17:14 -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 s9KEGwbm027317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 10:17:02 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 20 Oct 2014 14:16:43 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 10:16:42 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//w2+w Date: Mon, 20 Oct 2014 14:16:42 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605741C6A@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> In-Reply-To: <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=8nJ] X-AnalysisOut: [EP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HLLxP2VMA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=ElLe6oK6muH6aB43SuYA:9 a=wPNLvfGT] X-AnalysisOut: [eEIA:10 a=-zy3ex45pM4A:10 a=lZB815dzVvQA:10 a=vRAbILRZcFsA] X-AnalysisOut: [:10 a=1mYWI1HGygIcEEpS:21 a=G6j1lMca-s0qxkPu:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/0Mh2w7ugWVmzz7DP0CniuHVNNaw Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 14:42:53 -0000 I don't want to rehash the history of ENUM and I recognize there are some t= asks it doesn't do well. I will, however, be skeptical of any one-off proto= col for managing E.164 public user identities. I would expect that, like EN= UM, whatever we come up with will be built on some more general protocol. I= would also like to see some technical commonality with the management of o= ther types of PUIDs. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, October 20, 2014 9:51 AM To: Henning Schulzrinne Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g Subject: Re: [Modern] Services I really would like to get away from DNS entirely. We can reuse concepts, = but I think DNS is not the appropriate way to get anything to do with E.164= s. ENUM was a mistake, and one of the mistakes was using DNS. It's not the ap= propriate query mechanism, and it has a golden root problem. I remember we= ll the DNS guys questioning whether DNS was the right protocol when we star= ted ENUM. We were so sure it was. It was a mistake then, and it is now. Let's learn from that and stay away from DNS. =20 We need a query with TN and service that returns either some form of servic= e provider id/service URL and/or some form of route. I personally think th= at it would be best to keep route separate from service provider id/URL bec= ause I do think the user controls that part of the record while the SP cont= rols the route. Brian > On Oct 19, 2014, at 8:38 PM, Henning Schulzrinne wrote: >=20 > This isn't *that* new, although obviously at a new scale. For example, th= ere are many domain-specific URN schemes (e.g., DOIs for science publicatio= ns) that are assigned outside ICANN control, but interact with DNS. >=20 > We already have very basic mapping from numbers to domain names or IP add= resses in the existing databases (and most certainly in the VRS numbering d= atabase), so this is not fundamentally new even for phone numbers. >=20 > Besides the who-won't-like-it question, we already have a number space no= t managed by carriers, namely 800#. They illustrate to some extent that thi= s can work technically, but preventing hoarding may require more scalable m= echanisms than relying on kicking misbehaving entities out of the club. >=20 > Thus, as a strawman, I could picture that the number record returned by a= query returns (optionally) a domain name, resolved via DNS SRV or NAPTR as= the next step. This allows various combinations of managed-by-carrier and = managed-by-end user, depending on who gets to manage the DNS entry and who = gets to manage the number record. This then becomes a policy knob, beyond t= he MODERN discussion. >=20 > ________________________________________ > From: Richard Shockey [richard@shockey.us] > Sent: Saturday, October 18, 2014 8:30 PM > To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Ro= sen > Cc: modern@ietf.org > Subject: Re: [Modern] Services >=20 > In general I=B9d agree that a phone number is essentially a domain in the > classic theory of the abstraction of naming and addressing. That domain > should be consumer enterprise centric and carriers will ultimately IMHO > manage that service but I can also see the classic resistance of service > providers to the larger issue of number administration by consumers etc. >=20 > We=B9ve seen number administration become a classic barrier to entry for > competitors. I can site cases if anyone is interested. >=20 > But the larger thrust here is something more interesting. What is the > real alternative to DNS for different classes of names outside the ICANN > model. Istnt that what we are talking about? We accept and create a > model of resolution of one class of names E.164 totally outside the ICANN > model of administration. >=20 > NGN ENUM not using DNS preserving the traditional rights of nation states > to administer their portions of the numbering plan? >=20 > I=B9m just thinking. >=20 From nobody Mon Oct 20 08:38:34 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95241A1BC0 for ; Mon, 20 Oct 2014 08:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URI_TRY_3LD=0.001] autolearn=ham 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 UtObcAZkLUGk for ; Mon, 20 Oct 2014 08:38:28 -0700 (PDT) Received: from agamemnon.swishmail.com (agamemnon.swishmail.com [208.72.57.30]) (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 C1A881A1B04 for ; Mon, 20 Oct 2014 08:36:32 -0700 (PDT) Received: (qmail 34708 invoked by uid 89); 20 Oct 2014 15:36:27 -0000 Received: from unknown (HELO dranalliWin7) (dranalli@netnumber.com@75.150.73.57) by agamemnon.swishmail.com with ESMTPA; 20 Oct 2014 15:36:27 -0000 From: "Douglas Ranalli" To: "'Henning Schulzrinne'" , "'Brian Rosen'" References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> , <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> In-Reply-To: Date: Mon, 20 Oct 2014 11:36:25 -0400 Message-ID: <00fa01cfec7b$9ccfa460$d66eed20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegAATOQA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/modern/nrAVKfrabo6HowDDE9tdASJdYuQ Cc: "'Gorman, Pierce A \[NTK\]'" , modern@ietf.org, "'PFAUTZ, PENN L'" , 'Richard Shockey' Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:38:31 -0000 Henning and Brian, Great discussion over the past week. There might be some value in breaking the discussion down into separate distinct concepts. Here's a strawman to consider: - Concept-1: Number Allocation: Today, numbers are assigned as code-ranges to licensed carriers. The group has already explored several possible enhancements. Seems like the direction is to move towards more granular allocation of numbers (perhaps TN specific) to a broader set of industry players (not just licensed carriers). Lots of interesting policy decisions here that eventually need to be reflected in an underlying implementation. - Concept-2: Multiple SPs Per TN: The concept of multiple-services associated with a TN seems like an important advancement from our current telephony architecture. The group has explored this from several angles. Key policy issue is to guarantee a user's right to select more than one SP to provide services associated with the single TN. Key technology issue is to define how multiple services are discovered. Brian, your note below proposes a query for "TN and service". I like the idea of being able to ask for a single "service" but I think a mechanism is necessary to discover all of the services associated with a TN as well. - Concept-3: Service Provider ID: We've seen from experience that the minimum requirement for reaching a given service associated with a given TN is identifying some type of unique "service-provider ID" associated with the service. I draw this out as a separate concept because it involves agreement on a global naming convention that works for licensed carriers/operators, OTT providers, enterprises, etc. We're still missing a globally unique service-provider-ID mechanism that can be managed by the industry. I see value in separating the concept of service-provider discovery from route-discovery. - Concept-4: Routing: The final step is to establish a connection/session with the destination service-provider. I agree with Brian that the mechanism for defining the route is separate from the mechanism for defining the service-provider-ID. The user selects a service-provider for a given service. The originating and terminating service-providers both have a role to play in defining if/when/how to route to a given service. Current experience with SIP interconnect suggests that every originating SP can define its own local routing policy for reaching a given destination service. The solution involves bilateral interconnect discussions that are slow but it works. Alternatively we can explore a dynamic route-discovery mechanism that provides for destination-specific entry-point discovery that might vary by origin. I like the idea of dynamic discovery because it aligns with the general trend towards mobility in all forms of communication. Doug -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, October 20, 2014 9:58 AM To: Brian Rosen Cc: Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, PENN L; Richard Shockey Subject: Re: [Modern] Services I suspect we're talking past each other. I'm not advocating a "golden root" or anything that looks like ENUM number-based mapping. As a strawman, consider a JSON response within the MODERN context to a query for a phone number, returning for you "media": "myphone.brianrosen.net" with myphone.brianrosen.net resolving to _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. I assume we don't want to put IP addresses directly into the response, so DNS enters the picture at some point. The alternative is to use the SRV or NAPTR service field (here, _sip._tcp) directly in the MODERN response. I can see advantages to both. Henning ________________________________________ From: Brian Rosen [br@brianrosen.net] Sent: Monday, October 20, 2014 9:51 AM To: Henning Schulzrinne Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.org Subject: Re: [Modern] Services I really would like to get away from DNS entirely. We can reuse concepts, but I think DNS is not the appropriate way to get anything to do with E.164s. ENUM was a mistake, and one of the mistakes was using DNS. It's not the appropriate query mechanism, and it has a golden root problem. I remember well the DNS guys questioning whether DNS was the right protocol when we started ENUM. We were so sure it was. It was a mistake then, and it is now. Let's learn from that and stay away from DNS. We need a query with TN and service that returns either some form of service provider id/service URL and/or some form of route. I personally think that it would be best to keep route separate from service provider id/URL because I do think the user controls that part of the record while the SP controls the route. Brian _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern From nobody Mon Oct 20 09:08:00 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6769E1A1B07 for ; Mon, 20 Oct 2014 09:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URI_TRY_3LD=0.001] autolearn=ham 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 DVHVs4WdlfYW for ; Mon, 20 Oct 2014 09:07:56 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7590F1A01FA for ; Mon, 20 Oct 2014 09:06:44 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so3763579qgd.9 for ; Mon, 20 Oct 2014 09:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BKSO9TClxK4cztANx4AM+tbMkYl2AvFZH0/EyKX8AwA=; b=Q0aTDpnrE3ivVhIZ3bEsitOrnvG5c0dRrUdjkFCiFSlB0anza2Um3OyqwPJHiZTC95 sw/TWTCWknaqWmdttllqwitnE1qhDbPrtgHWC3as7CBy34ATX2Rh5cjDMOwpeHwvu5di 6m+q/GV7S0lrjiC4he3Pt0fhceGhudbz5wvQEEGMfi3+mPJ1b1Eux+oV3eRJ2pKIOdLD 9I5FRvE4UfiXP1gjn+dMaBD+7wGGEPmt91vXZ7MIrXT0h5Wa4NU2V4zV8fjmWx8zgyxq ORrPYMHWVt6Fn4p0v8aT4FgAj8LXuPzhC7cu0GhpIaMcf0DRKRycuPrJzny1IlwwWN1r z46g== X-Gm-Message-State: ALoCoQmwKth6hJce0fwHpIDp5Vb2Q8fi1kbTMtvJHYYHI2G6kAkswh8LtNmbZ/6XSdOWEi+ioY2A X-Received: by 10.224.152.5 with SMTP id e5mr26540113qaw.48.1413821203128; Mon, 20 Oct 2014 09:06:43 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id h79sm8205714qgd.27.2014.10.20.09.06.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 09:06:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: <00fa01cfec7b$9ccfa460$d66eed20$@com> Date: Mon, 20 Oct 2014 12:06:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <, > <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> To: Douglas Ranalli X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/AoIRVCGuNrXrjsnPpS1yDz2SDNg Cc: "Gorman, Pierce A \[NTK\]" , modern@ietf.org, "PFAUTZ, PENN L" , Richard Shockey , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:07:58 -0000 I like the way you are thinking. I do want to pick out your number 3. It may very well be that what we want is a SPID. I would like to figure = out if SPID is actually what we want before we start going down the path = of creating a new identifier. You want a SPID when an entity doing a query has some sort of database = that can translate SPID to something else. A good example might be you = have peering relationships with some SPs, but for others, you use a = transit provider. You have a database by SPID of which provider you = send a call to. I like that example because you would not put that = information in some common database - it=E2=80=99s local to you. But, do we need an SPID that is different from a domain name? Domain = Names are unique, so that=E2=80=99s one thing we need. They are easy to = create, and we already have a management process. I think the downside = is that not all domains are SPIDs, and we might need to know the = difference. Another one is because they are cheap, they may proliferate = in ways detrimental to maintaining things like routing databases. But, as a straw man, what is wrong with domain name as SPID? Brian > On Oct 20, 2014, at 11:36 AM, Douglas Ranalli = wrote: >=20 > Henning and Brian, >=20 > Great discussion over the past week. There might be some value in = breaking > the discussion down into separate distinct concepts. Here's a = strawman to > consider: >=20 > - Concept-1: Number Allocation: Today, numbers are assigned as = code-ranges > to licensed carriers. The group has already explored several possible > enhancements. Seems like the direction is to move towards more = granular > allocation of numbers (perhaps TN specific) to a broader set of = industry > players (not just licensed carriers). Lots of interesting policy = decisions > here that eventually need to be reflected in an underlying = implementation. >=20 >=20 > - Concept-2: Multiple SPs Per TN: The concept of multiple-services > associated with a TN seems like an important advancement from our = current > telephony architecture. The group has explored this from several = angles. > Key policy issue is to guarantee a user's right to select more than = one SP > to provide services associated with the single TN. Key technology = issue is > to define how multiple services are discovered. Brian, your note = below > proposes a query for "TN and service". I like the idea of being able = to ask > for a single "service" but I think a mechanism is necessary to = discover all > of the services associated with a TN as well. =20 >=20 > - Concept-3: Service Provider ID: We've seen from experience that the > minimum requirement for reaching a given service associated with a = given TN > is identifying some type of unique "service-provider ID" associated = with the > service. I draw this out as a separate concept because it involves > agreement on a global naming convention that works for licensed > carriers/operators, OTT providers, enterprises, etc. We're still = missing a > globally unique service-provider-ID mechanism that can be managed by = the > industry. I see value in separating the concept of service-provider > discovery from route-discovery. =20 >=20 > - Concept-4: Routing: The final step is to establish a = connection/session > with the destination service-provider. I agree with Brian that the > mechanism for defining the route is separate from the mechanism for = defining > the service-provider-ID. The user selects a service-provider for a = given > service. The originating and terminating service-providers both have = a role > to play in defining if/when/how to route to a given service. Current > experience with SIP interconnect suggests that every originating SP = can > define its own local routing policy for reaching a given destination > service. The solution involves bilateral interconnect discussions that = are > slow but it works. Alternatively we can explore a dynamic = route-discovery > mechanism that provides for destination-specific entry-point discovery = that > might vary by origin. I like the idea of dynamic discovery because it > aligns with the general trend towards mobility in all forms of > communication.=20 >=20 > Doug >=20 >=20 >=20 > -----Original Message----- > From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning > Schulzrinne > Sent: Monday, October 20, 2014 9:58 AM > To: Brian Rosen > Cc: Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, PENN L; Richard = Shockey > Subject: Re: [Modern] Services >=20 > I suspect we're talking past each other. I'm not advocating a "golden = root" > or anything that looks like ENUM number-based mapping. As a strawman, > consider a JSON response within the MODERN context to a query for a = phone > number, returning for you >=20 > "media": "myphone.brianrosen.net" >=20 > with myphone.brianrosen.net >=20 > resolving to >=20 > _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >=20 >=20 > I assume we don't want to put IP addresses directly into the response, = so > DNS enters the picture at some point. >=20 > The alternative is to use the SRV or NAPTR service field (here, = _sip._tcp) > directly in the MODERN response. I can see advantages to both. >=20 > Henning >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 9:51 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = modern@ietf.org > Subject: Re: [Modern] Services >=20 > I really would like to get away from DNS entirely. We can reuse = concepts, > but I think DNS is not the appropriate way to get anything to do with > E.164s. > ENUM was a mistake, and one of the mistakes was using DNS. It's not = the > appropriate query mechanism, and it has a golden root problem. I = remember > well the DNS guys questioning whether DNS was the right protocol when = we > started ENUM. We were so sure it was. It was a mistake then, and it = is > now. >=20 > Let's learn from that and stay away from DNS. >=20 > We need a query with TN and service that returns either some form of = service > provider id/service URL and/or some form of route. I personally think = that > it would be best to keep route separate from service provider id/URL = because > I do think the user controls that part of the record while the SP = controls > the route. >=20 > Brian > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern >=20 From nobody Mon Oct 20 09:36:31 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3211A908F for ; Mon, 20 Oct 2014 09:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 nwXSBFhaV713 for ; Mon, 20 Oct 2014 09:36:19 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827C81A8A1A for ; Mon, 20 Oct 2014 09:25:30 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id a7735445.2b3b46616940.7877074.00-2413.22159573.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 20 Oct 2014 16:25:30 +0000 (UTC) X-MXL-Hash: 5445377a679b47b1-df6c37a0a6e12dafc6defaff4bcb87bc65607669 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 76735445.0.7876867.00-1930.22158922.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 20 Oct 2014 16:25:15 +0000 (UTC) X-MXL-Hash: 5445376b1e0753bf-c83812472eef201b0ca481d4677693f72f4af42d 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 s9KGPAPc001562; Mon, 20 Oct 2014 12:25:11 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9KGOo7Y000933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 12:24:53 -0400 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 20 Oct 2014 16:24:35 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:24:35 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Douglas Ranalli Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegAATOQCAAFVQAP//wSzg Date: Mon, 20 Oct 2014 16:24:34 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605741DB8@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> In-Reply-To: <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=ae/Wa2Ut c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=Ikc] X-AnalysisOut: [TkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=8A7brI4kj] X-AnalysisOut: [U8C6ETGAX3PRdgeao0=:19 a=5Mz7otzJAAAA:8 a=HLLxP2VMAAAA:8 a] X-AnalysisOut: [=48vgC7mUAAAA:8 a=4GpaQDp7AAAA:8 a=A1X0JdhQAAAA:8 a=0optqk] X-AnalysisOut: [GP9KWFBgnn7B0A:9 a=QEXdDO2ut3YA:10 a=-zy3ex45pM4A:10 a=lZB] X-AnalysisOut: [815dzVvQA:10 a=FdVBEsWhMeQA:10 a=Y6nCLOkMOQhHNBJB:21 a=54V] X-AnalysisOut: [aAbxXRZ5JOxuC:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/J9KZBcSlKcfzzzjkIKJtwJdjfjI Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:36:27 -0000 QnJpYW46DQpUaGUgaTMgRm9ydW0gZGlkIGEgYml0IG9mIHdvcmsgb24gU1BJRCAoc2VlIGh0dHA6 Ly9pM2ZvcnVtLm9yZy9pM2ZvcnVtLWdsb2JhbC1zcGlkLXNwZWNpZmljYXRpb25zLXJlbGVhc2Ut MS1tYXktMjAxMS8pDQpUaGVyZSB3ZXJlIHNvbWUgcGFydGllcyB0aGF0IHdhbnRlZCBhIG51bWVy aWMgaWRlbnRpZmllciwgYnV0IGFzIHdpdGggRU5VTSwgdGhlIGJpZ2dlc3QgaXNzdWVzIHdlcmUg bm90IHRlY2huaWNhbCBidXQgYnVzaW5lc3MgaW4gdGVybXMgb2YgZ2V0dGluZyBhZ3JlZW1lbnQg b24gd2hvIHdvdWxkIGFkbWluaXN0ZXIgU1BJRC4gSSB0b29rIGEgcnVuIGF0IGEgbnVtYmVyIG9m IGFsdGVybmF0aXZlcywgSUFOQSwgSVRVLCBSSVIsIHdpdGhvdXQgcmVhbGx5IGdldHRpbmcgYW55 d2hlcmUuIFRoZXJlIHdhcyBzb21lIHN1Z2dlc3Rpb24gdGhlIEdTTUEgbWlnaHQgc3RlcCB1cC4N CldlIGRvIHdhbnQgc29tZXRoaW5nIGdsb2JhbC4NCg0KUGVubg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gUm9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0g DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjAsIDIwMTQgMTI6MDcgUE0NClRvOiBEb3VnbGFzIFJh bmFsbGkNCkNjOiBIZW5uaW5nIFNjaHVsenJpbm5lOyBHb3JtYW4sIFBpZXJjZSBBIFtOVEtdOyBt b2Rlcm5AaWV0Zi5vcmc7IFBGQVVUWiwgUEVOTiBMOyBSaWNoYXJkIFNob2NrZXkNClN1YmplY3Q6 IFJlOiBbTW9kZXJuXSBTZXJ2aWNlcw0KDQpJIGxpa2UgdGhlIHdheSB5b3UgYXJlIHRoaW5raW5n Lg0KDQpJIGRvIHdhbnQgdG8gcGljayBvdXQgeW91ciBudW1iZXIgMy4NCg0KSXQgbWF5IHZlcnkg d2VsbCBiZSB0aGF0IHdoYXQgd2Ugd2FudCBpcyBhIFNQSUQuICBJIHdvdWxkIGxpa2UgdG8gZmln dXJlIG91dCBpZiBTUElEIGlzIGFjdHVhbGx5IHdoYXQgd2Ugd2FudCBiZWZvcmUgd2Ugc3RhcnQg Z29pbmcgZG93biB0aGUgcGF0aCBvZiBjcmVhdGluZyBhIG5ldyBpZGVudGlmaWVyLg0KDQpZb3Ug d2FudCBhIFNQSUQgd2hlbiBhbiBlbnRpdHkgZG9pbmcgYSBxdWVyeSBoYXMgc29tZSBzb3J0IG9m IGRhdGFiYXNlIHRoYXQgY2FuIHRyYW5zbGF0ZSBTUElEIHRvIHNvbWV0aGluZyBlbHNlLiAgQSBn b29kIGV4YW1wbGUgbWlnaHQgYmUgeW91IGhhdmUgcGVlcmluZyByZWxhdGlvbnNoaXBzIHdpdGgg c29tZSBTUHMsIGJ1dCBmb3Igb3RoZXJzLCB5b3UgdXNlIGEgdHJhbnNpdCBwcm92aWRlci4gIFlv dSBoYXZlIGEgZGF0YWJhc2UgYnkgU1BJRCBvZiB3aGljaCBwcm92aWRlciB5b3Ugc2VuZCBhIGNh bGwgdG8uICAgSSBsaWtlIHRoYXQgZXhhbXBsZSBiZWNhdXNlIHlvdSB3b3VsZCBub3QgcHV0IHRo YXQgaW5mb3JtYXRpb24gaW4gc29tZSBjb21tb24gZGF0YWJhc2UgLSBpdOKAmXMgbG9jYWwgdG8g eW91Lg0KDQpCdXQsIGRvIHdlIG5lZWQgYW4gU1BJRCB0aGF0IGlzIGRpZmZlcmVudCBmcm9tIGEg ZG9tYWluIG5hbWU/ICBEb21haW4gTmFtZXMgYXJlIHVuaXF1ZSwgc28gdGhhdOKAmXMgb25lIHRo aW5nIHdlIG5lZWQuICBUaGV5IGFyZSBlYXN5IHRvIGNyZWF0ZSwgYW5kIHdlIGFscmVhZHkgaGF2 ZSBhIG1hbmFnZW1lbnQgcHJvY2Vzcy4gIEkgdGhpbmsgdGhlIGRvd25zaWRlIGlzIHRoYXQgbm90 IGFsbCBkb21haW5zIGFyZSBTUElEcywgYW5kIHdlIG1pZ2h0IG5lZWQgdG8ga25vdyB0aGUgZGlm ZmVyZW5jZS4gIEFub3RoZXIgb25lIGlzIGJlY2F1c2UgdGhleSBhcmUgY2hlYXAsIHRoZXkgbWF5 IHByb2xpZmVyYXRlIGluIHdheXMgZGV0cmltZW50YWwgdG8gbWFpbnRhaW5pbmcgdGhpbmdzIGxp a2Ugcm91dGluZyBkYXRhYmFzZXMuDQoNCkJ1dCwgYXMgYSBzdHJhdyBtYW4sIHdoYXQgaXMgd3Jv bmcgd2l0aCBkb21haW4gbmFtZSBhcyBTUElEPw0KDQpCcmlhbg0KDQo+IE9uIE9jdCAyMCwgMjAx NCwgYXQgMTE6MzYgQU0sIERvdWdsYXMgUmFuYWxsaSA8ZHJhbmFsbGlAbmV0bnVtYmVyLmNvbT4g d3JvdGU6DQo+IA0KPiBIZW5uaW5nIGFuZCBCcmlhbiwNCj4gDQo+IEdyZWF0IGRpc2N1c3Npb24g b3ZlciB0aGUgcGFzdCB3ZWVrLiAgVGhlcmUgbWlnaHQgYmUgc29tZSB2YWx1ZSBpbiBicmVha2lu Zw0KPiB0aGUgZGlzY3Vzc2lvbiBkb3duIGludG8gc2VwYXJhdGUgZGlzdGluY3QgY29uY2VwdHMu ICBIZXJlJ3MgYSBzdHJhd21hbiB0bw0KPiBjb25zaWRlcjoNCj4gDQo+IC0gQ29uY2VwdC0xOiAg TnVtYmVyIEFsbG9jYXRpb246ICBUb2RheSwgbnVtYmVycyBhcmUgYXNzaWduZWQgYXMgY29kZS1y YW5nZXMNCj4gdG8gbGljZW5zZWQgY2FycmllcnMuICBUaGUgZ3JvdXAgaGFzIGFscmVhZHkgZXhw bG9yZWQgc2V2ZXJhbCBwb3NzaWJsZQ0KPiBlbmhhbmNlbWVudHMuICBTZWVtcyBsaWtlIHRoZSBk aXJlY3Rpb24gaXMgdG8gbW92ZSB0b3dhcmRzIG1vcmUgZ3JhbnVsYXINCj4gYWxsb2NhdGlvbiBv ZiBudW1iZXJzIChwZXJoYXBzIFROIHNwZWNpZmljKSB0byBhIGJyb2FkZXIgc2V0IG9mIGluZHVz dHJ5DQo+IHBsYXllcnMgKG5vdCBqdXN0IGxpY2Vuc2VkIGNhcnJpZXJzKS4gIExvdHMgb2YgaW50 ZXJlc3RpbmcgcG9saWN5IGRlY2lzaW9ucw0KPiBoZXJlIHRoYXQgZXZlbnR1YWxseSBuZWVkIHRv IGJlIHJlZmxlY3RlZCBpbiBhbiB1bmRlcmx5aW5nIGltcGxlbWVudGF0aW9uLg0KPiANCj4gDQo+ IC0gQ29uY2VwdC0yOiAgTXVsdGlwbGUgU1BzIFBlciBUTjogIFRoZSBjb25jZXB0IG9mIG11bHRp cGxlLXNlcnZpY2VzDQo+IGFzc29jaWF0ZWQgd2l0aCBhIFROIHNlZW1zIGxpa2UgYW4gaW1wb3J0 YW50IGFkdmFuY2VtZW50IGZyb20gb3VyIGN1cnJlbnQNCj4gdGVsZXBob255IGFyY2hpdGVjdHVy ZS4gIFRoZSBncm91cCBoYXMgZXhwbG9yZWQgdGhpcyBmcm9tIHNldmVyYWwgYW5nbGVzLg0KPiBL ZXkgcG9saWN5IGlzc3VlIGlzIHRvIGd1YXJhbnRlZSBhIHVzZXIncyByaWdodCB0byBzZWxlY3Qg bW9yZSB0aGFuIG9uZSBTUA0KPiB0byBwcm92aWRlIHNlcnZpY2VzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgc2luZ2xlIFROLiAgS2V5IHRlY2hub2xvZ3kgaXNzdWUgaXMNCj4gdG8gZGVmaW5lIGhvdyBt dWx0aXBsZSBzZXJ2aWNlcyBhcmUgZGlzY292ZXJlZC4gIEJyaWFuLCB5b3VyIG5vdGUgYmVsb3cN Cj4gcHJvcG9zZXMgYSBxdWVyeSBmb3IgIlROIGFuZCBzZXJ2aWNlIi4gIEkgbGlrZSB0aGUgaWRl YSBvZiBiZWluZyBhYmxlIHRvIGFzaw0KPiBmb3IgYSBzaW5nbGUgInNlcnZpY2UiIGJ1dCBJIHRo aW5rIGEgbWVjaGFuaXNtIGlzIG5lY2Vzc2FyeSB0byBkaXNjb3ZlciBhbGwNCj4gb2YgdGhlIHNl cnZpY2VzIGFzc29jaWF0ZWQgd2l0aCBhIFROIGFzIHdlbGwuICANCj4gDQo+IC0gQ29uY2VwdC0z OiBTZXJ2aWNlIFByb3ZpZGVyIElEOiAgV2UndmUgc2VlbiBmcm9tIGV4cGVyaWVuY2UgdGhhdCB0 aGUNCj4gbWluaW11bSByZXF1aXJlbWVudCBmb3IgcmVhY2hpbmcgYSBnaXZlbiBzZXJ2aWNlIGFz c29jaWF0ZWQgd2l0aCBhIGdpdmVuIFRODQo+IGlzIGlkZW50aWZ5aW5nIHNvbWUgdHlwZSBvZiB1 bmlxdWUgInNlcnZpY2UtcHJvdmlkZXIgSUQiIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4gc2Vydmlj ZS4gIEkgZHJhdyB0aGlzIG91dCBhcyBhIHNlcGFyYXRlIGNvbmNlcHQgYmVjYXVzZSBpdCBpbnZv bHZlcw0KPiBhZ3JlZW1lbnQgb24gYSBnbG9iYWwgbmFtaW5nIGNvbnZlbnRpb24gdGhhdCB3b3Jr cyBmb3IgbGljZW5zZWQNCj4gY2FycmllcnMvb3BlcmF0b3JzLCBPVFQgcHJvdmlkZXJzLCBlbnRl cnByaXNlcywgZXRjLiAgV2UncmUgc3RpbGwgbWlzc2luZyBhDQo+IGdsb2JhbGx5IHVuaXF1ZSBz ZXJ2aWNlLXByb3ZpZGVyLUlEIG1lY2hhbmlzbSB0aGF0IGNhbiBiZSBtYW5hZ2VkIGJ5IHRoZQ0K PiBpbmR1c3RyeS4gIEkgc2VlIHZhbHVlIGluIHNlcGFyYXRpbmcgdGhlIGNvbmNlcHQgb2Ygc2Vy dmljZS1wcm92aWRlcg0KPiBkaXNjb3ZlcnkgZnJvbSByb3V0ZS1kaXNjb3ZlcnkuICAgDQo+IA0K PiAtIENvbmNlcHQtNDogUm91dGluZzogIFRoZSBmaW5hbCBzdGVwIGlzIHRvIGVzdGFibGlzaCBh IGNvbm5lY3Rpb24vc2Vzc2lvbg0KPiB3aXRoIHRoZSBkZXN0aW5hdGlvbiBzZXJ2aWNlLXByb3Zp ZGVyLiAgSSBhZ3JlZSB3aXRoIEJyaWFuIHRoYXQgdGhlDQo+IG1lY2hhbmlzbSBmb3IgZGVmaW5p bmcgdGhlIHJvdXRlIGlzIHNlcGFyYXRlIGZyb20gdGhlIG1lY2hhbmlzbSBmb3IgZGVmaW5pbmcN Cj4gdGhlIHNlcnZpY2UtcHJvdmlkZXItSUQuICBUaGUgdXNlciBzZWxlY3RzIGEgc2VydmljZS1w cm92aWRlciBmb3IgYSBnaXZlbg0KPiBzZXJ2aWNlLiAgVGhlIG9yaWdpbmF0aW5nIGFuZCB0ZXJt aW5hdGluZyBzZXJ2aWNlLXByb3ZpZGVycyBib3RoIGhhdmUgYSByb2xlDQo+IHRvIHBsYXkgaW4g ZGVmaW5pbmcgaWYvd2hlbi9ob3cgdG8gcm91dGUgdG8gYSBnaXZlbiBzZXJ2aWNlLiAgQ3VycmVu dA0KPiBleHBlcmllbmNlIHdpdGggU0lQIGludGVyY29ubmVjdCBzdWdnZXN0cyB0aGF0IGV2ZXJ5 IG9yaWdpbmF0aW5nIFNQIGNhbg0KPiBkZWZpbmUgaXRzIG93biBsb2NhbCByb3V0aW5nIHBvbGlj eSBmb3IgcmVhY2hpbmcgYSBnaXZlbiBkZXN0aW5hdGlvbg0KPiBzZXJ2aWNlLiBUaGUgc29sdXRp b24gaW52b2x2ZXMgYmlsYXRlcmFsIGludGVyY29ubmVjdCBkaXNjdXNzaW9ucyB0aGF0IGFyZQ0K PiBzbG93IGJ1dCBpdCB3b3Jrcy4gIEFsdGVybmF0aXZlbHkgd2UgY2FuIGV4cGxvcmUgYSBkeW5h bWljIHJvdXRlLWRpc2NvdmVyeQ0KPiBtZWNoYW5pc20gdGhhdCBwcm92aWRlcyBmb3IgZGVzdGlu YXRpb24tc3BlY2lmaWMgZW50cnktcG9pbnQgZGlzY292ZXJ5IHRoYXQNCj4gbWlnaHQgdmFyeSBi eSBvcmlnaW4uICBJIGxpa2UgdGhlIGlkZWEgb2YgZHluYW1pYyBkaXNjb3ZlcnkgYmVjYXVzZSBp dA0KPiBhbGlnbnMgd2l0aCB0aGUgZ2VuZXJhbCB0cmVuZCB0b3dhcmRzIG1vYmlsaXR5IGluIGFs bCBmb3JtcyBvZg0KPiBjb21tdW5pY2F0aW9uLiANCj4gDQo+IERvdWcNCj4gDQo+IA0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTW9kZXJuIFttYWlsdG86bW9kZXJu LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIZW5uaW5nDQo+IFNjaHVsenJpbm5lDQo+ IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAxNCA5OjU4IEFNDQo+IFRvOiBCcmlhbiBSb3Nl bg0KPiBDYzogR29ybWFuLCBQaWVyY2UgQSBbTlRLXTsgbW9kZXJuQGlldGYub3JnOyBQRkFVVFos IFBFTk4gTDsgUmljaGFyZCBTaG9ja2V5DQo+IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBTZXJ2aWNl cw0KPiANCj4gSSBzdXNwZWN0IHdlJ3JlIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVyLiBJJ20gbm90 IGFkdm9jYXRpbmcgYSAiZ29sZGVuIHJvb3QiDQo+IG9yIGFueXRoaW5nIHRoYXQgbG9va3MgbGlr ZSBFTlVNIG51bWJlci1iYXNlZCBtYXBwaW5nLiBBcyBhIHN0cmF3bWFuLA0KPiBjb25zaWRlciBh IEpTT04gcmVzcG9uc2Ugd2l0aGluIHRoZSBNT0RFUk4gY29udGV4dCB0byBhIHF1ZXJ5IGZvciBh IHBob25lDQo+IG51bWJlciwgcmV0dXJuaW5nIGZvciB5b3UNCj4gDQo+ICJtZWRpYSI6ICJteXBo b25lLmJyaWFucm9zZW4ubmV0Ig0KPiANCj4gd2l0aCBteXBob25lLmJyaWFucm9zZW4ubmV0DQo+ IA0KPiByZXNvbHZpbmcgdG8NCj4gDQo+IF9zaXAuX3RjcC5leGFtcGxlLmNvbS4gODY0MDAgSU4g U1JWIDAgNSA1MDYwIHNpcHNlcnZlci5leGFtcGxlLmNvbS4NCj4gDQo+IA0KPiBJIGFzc3VtZSB3 ZSBkb24ndCB3YW50IHRvIHB1dCBJUCBhZGRyZXNzZXMgZGlyZWN0bHkgaW50byB0aGUgcmVzcG9u c2UsIHNvDQo+IEROUyBlbnRlcnMgdGhlIHBpY3R1cmUgYXQgc29tZSBwb2ludC4NCj4gDQo+IFRo ZSBhbHRlcm5hdGl2ZSBpcyB0byB1c2UgdGhlIFNSViBvciBOQVBUUiBzZXJ2aWNlIGZpZWxkICho ZXJlLCBfc2lwLl90Y3ApDQo+IGRpcmVjdGx5IGluIHRoZSBNT0RFUk4gcmVzcG9uc2UuIEkgY2Fu IHNlZSBhZHZhbnRhZ2VzIHRvIGJvdGguDQo+IA0KPiBIZW5uaW5nDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IEJyaWFuIFJvc2VuIFtickBi cmlhbnJvc2VuLm5ldF0NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAyMDE0IDk6NTEgQU0N Cj4gVG86IEhlbm5pbmcgU2NodWx6cmlubmUNCj4gQ2M6IFJpY2hhcmQgU2hvY2tleTsgUEZBVVRa LCBQRU5OIEw7IEdvcm1hbiwgUGllcmNlIEEgW05US107IG1vZGVybkBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW01vZGVybl0gU2VydmljZXMNCj4gDQo+IEkgcmVhbGx5IHdvdWxkIGxpa2UgdG8g Z2V0IGF3YXkgZnJvbSBETlMgZW50aXJlbHkuICBXZSBjYW4gcmV1c2UgY29uY2VwdHMsDQo+IGJ1 dCBJIHRoaW5rIEROUyBpcyBub3QgdGhlIGFwcHJvcHJpYXRlIHdheSB0byBnZXQgYW55dGhpbmcg dG8gZG8gd2l0aA0KPiBFLjE2NHMuDQo+IEVOVU0gd2FzIGEgbWlzdGFrZSwgYW5kIG9uZSBvZiB0 aGUgbWlzdGFrZXMgd2FzIHVzaW5nIEROUy4gIEl0J3Mgbm90IHRoZQ0KPiBhcHByb3ByaWF0ZSBx dWVyeSBtZWNoYW5pc20sIGFuZCBpdCBoYXMgYSBnb2xkZW4gcm9vdCBwcm9ibGVtLiAgSSByZW1l bWJlcg0KPiB3ZWxsIHRoZSBETlMgZ3V5cyBxdWVzdGlvbmluZyB3aGV0aGVyIEROUyB3YXMgdGhl IHJpZ2h0IHByb3RvY29sIHdoZW4gd2UNCj4gc3RhcnRlZCBFTlVNLiAgV2Ugd2VyZSBzbyBzdXJl IGl0IHdhcy4gIEl0IHdhcyBhIG1pc3Rha2UgdGhlbiwgYW5kIGl0IGlzDQo+IG5vdy4NCj4gDQo+ IExldCdzIGxlYXJuIGZyb20gdGhhdCBhbmQgc3RheSBhd2F5IGZyb20gRE5TLg0KPiANCj4gV2Ug bmVlZCBhIHF1ZXJ5IHdpdGggVE4gYW5kIHNlcnZpY2UgdGhhdCByZXR1cm5zIGVpdGhlciBzb21l IGZvcm0gb2Ygc2VydmljZQ0KPiBwcm92aWRlciBpZC9zZXJ2aWNlIFVSTCBhbmQvb3Igc29tZSBm b3JtIG9mIHJvdXRlLiAgSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQNCj4gaXQgd291bGQgYmUgYmVz dCB0byBrZWVwIHJvdXRlIHNlcGFyYXRlIGZyb20gc2VydmljZSBwcm92aWRlciBpZC9VUkwgYmVj YXVzZQ0KPiBJIGRvIHRoaW5rIHRoZSB1c2VyIGNvbnRyb2xzIHRoYXQgcGFydCBvZiB0aGUgcmVj b3JkIHdoaWxlIHRoZSBTUCBjb250cm9scw0KPiB0aGUgcm91dGUuDQo+IA0KPiBCcmlhbg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNb2Rlcm4g bWFpbGluZyBsaXN0DQo+IE1vZGVybkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21vZGVybg0KPiANCg0K From nobody Mon Oct 20 09:40:27 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED4B1A872C for ; Mon, 20 Oct 2014 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URI_TRY_3LD=0.001] autolearn=ham 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 8Eg-ksonD_S4 for ; Mon, 20 Oct 2014 09:40:21 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7512C1A87A8 for ; Mon, 20 Oct 2014 09:27:24 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id dc16so3510957qab.7 for ; Mon, 20 Oct 2014 09:27:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rdruYzNZveGk02k2chU0XPyByN7lbAsxN/uN38QRk0I=; b=PSKauFkvUd1sxsLF7Ar04VogcztLhTYxpKkGwGsCXUKTHBuqXFrsORw9bgVbnaFK60 o2Z0BBdgehIehzCTPpeUzBGINgkh8eFfZlOB/4H8Z7Pnf4sEfofyAO1AG7JQ3Eq/9/bM REfgavzbagUFZA0XO0V+hBcx314VTISwudQwqZTylhEmjFMjsbF+QUR9uTlfJ5lSEID3 XLxdr1YgQ3uOlsGrSKwL3ET1P9np2fwUFeSfdZuqmAgWu/GH+p+O91YvDbz/iv9zplB7 JsGt3AlLEfQBkznXRigSGXPC7d+y5i0u0fB2lReBkKU5diDFeC4NoLsiY3CbPjnCeqPU 1bpw== X-Gm-Message-State: ALoCoQkS9Qz0yEaHh+/5fVyaCWzQ5IpDwMTof5cAG5ulXpV+cC13gAYii3YSvP+GudPMMx7wEK8A X-Received: by 10.224.15.66 with SMTP id j2mr8295944qaa.53.1413822440062; Mon, 20 Oct 2014 09:27:20 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id e6sm8256973qab.42.2014.10.20.09.27.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 09:27:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: <38726EDA2109264987B45E29E758C4D605741DB8@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Mon, 20 Oct 2014 12:27:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC432DA-EA85-4FAD-A141-D449ECD00F0C@brianrosen.net> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <, > <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741DB8@MISOUT7MSGUSRDD.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/JqjIn6kepsFnUOmz8fs3l9Lznss Cc: "modern@ietf.org" , "Gorman, Pierce A \[NTK\]" , Douglas Ranalli , Richard Shockey , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:40:26 -0000 Yeah, I know. That=E2=80=99s why I want to question first principles. Do we need a SPID? Why won=E2=80=99t a domain name do? What properties = do we need in an ID beyond global uniqueness? Brian > On Oct 20, 2014, at 12:24 PM, PFAUTZ, PENN L wrote: >=20 > Brian: > The i3 Forum did a bit of work on SPID (see = http://i3forum.org/i3forum-global-spid-specifications-release-1-may-2011/)= > There were some parties that wanted a numeric identifier, but as with = ENUM, the biggest issues were not technical but business in terms of = getting agreement on who would administer SPID. I took a run at a number = of alternatives, IANA, ITU, RIR, without really getting anywhere. There = was some suggestion the GSMA might step up. > We do want something global. >=20 > Penn >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, October 20, 2014 12:07 PM > To: Douglas Ranalli > Cc: Henning Schulzrinne; Gorman, Pierce A [NTK]; modern@ietf.org; = PFAUTZ, PENN L; Richard Shockey > Subject: Re: [Modern] Services >=20 > I like the way you are thinking. >=20 > I do want to pick out your number 3. >=20 > It may very well be that what we want is a SPID. I would like to = figure out if SPID is actually what we want before we start going down = the path of creating a new identifier. >=20 > You want a SPID when an entity doing a query has some sort of database = that can translate SPID to something else. A good example might be you = have peering relationships with some SPs, but for others, you use a = transit provider. You have a database by SPID of which provider you = send a call to. I like that example because you would not put that = information in some common database - it=E2=80=99s local to you. >=20 > But, do we need an SPID that is different from a domain name? Domain = Names are unique, so that=E2=80=99s one thing we need. They are easy to = create, and we already have a management process. I think the downside = is that not all domains are SPIDs, and we might need to know the = difference. Another one is because they are cheap, they may proliferate = in ways detrimental to maintaining things like routing databases. >=20 > But, as a straw man, what is wrong with domain name as SPID? >=20 > Brian >=20 >> On Oct 20, 2014, at 11:36 AM, Douglas Ranalli = wrote: >>=20 >> Henning and Brian, >>=20 >> Great discussion over the past week. There might be some value in = breaking >> the discussion down into separate distinct concepts. Here's a = strawman to >> consider: >>=20 >> - Concept-1: Number Allocation: Today, numbers are assigned as = code-ranges >> to licensed carriers. The group has already explored several = possible >> enhancements. Seems like the direction is to move towards more = granular >> allocation of numbers (perhaps TN specific) to a broader set of = industry >> players (not just licensed carriers). Lots of interesting policy = decisions >> here that eventually need to be reflected in an underlying = implementation. >>=20 >>=20 >> - Concept-2: Multiple SPs Per TN: The concept of multiple-services >> associated with a TN seems like an important advancement from our = current >> telephony architecture. The group has explored this from several = angles. >> Key policy issue is to guarantee a user's right to select more than = one SP >> to provide services associated with the single TN. Key technology = issue is >> to define how multiple services are discovered. Brian, your note = below >> proposes a query for "TN and service". I like the idea of being able = to ask >> for a single "service" but I think a mechanism is necessary to = discover all >> of the services associated with a TN as well. =20 >>=20 >> - Concept-3: Service Provider ID: We've seen from experience that = the >> minimum requirement for reaching a given service associated with a = given TN >> is identifying some type of unique "service-provider ID" associated = with the >> service. I draw this out as a separate concept because it involves >> agreement on a global naming convention that works for licensed >> carriers/operators, OTT providers, enterprises, etc. We're still = missing a >> globally unique service-provider-ID mechanism that can be managed by = the >> industry. I see value in separating the concept of service-provider >> discovery from route-discovery. =20 >>=20 >> - Concept-4: Routing: The final step is to establish a = connection/session >> with the destination service-provider. I agree with Brian that the >> mechanism for defining the route is separate from the mechanism for = defining >> the service-provider-ID. The user selects a service-provider for a = given >> service. The originating and terminating service-providers both have = a role >> to play in defining if/when/how to route to a given service. Current >> experience with SIP interconnect suggests that every originating SP = can >> define its own local routing policy for reaching a given destination >> service. The solution involves bilateral interconnect discussions = that are >> slow but it works. Alternatively we can explore a dynamic = route-discovery >> mechanism that provides for destination-specific entry-point = discovery that >> might vary by origin. I like the idea of dynamic discovery because = it >> aligns with the general trend towards mobility in all forms of >> communication.=20 >>=20 >> Doug >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >> Schulzrinne >> Sent: Monday, October 20, 2014 9:58 AM >> To: Brian Rosen >> Cc: Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, PENN L; Richard = Shockey >> Subject: Re: [Modern] Services >>=20 >> I suspect we're talking past each other. I'm not advocating a "golden = root" >> or anything that looks like ENUM number-based mapping. As a strawman, >> consider a JSON response within the MODERN context to a query for a = phone >> number, returning for you >>=20 >> "media": "myphone.brianrosen.net" >>=20 >> with myphone.brianrosen.net >>=20 >> resolving to >>=20 >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>=20 >>=20 >> I assume we don't want to put IP addresses directly into the = response, so >> DNS enters the picture at some point. >>=20 >> The alternative is to use the SRV or NAPTR service field (here, = _sip._tcp) >> directly in the MODERN response. I can see advantages to both. >>=20 >> Henning >>=20 >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = modern@ietf.org >> Subject: Re: [Modern] Services >>=20 >> I really would like to get away from DNS entirely. We can reuse = concepts, >> but I think DNS is not the appropriate way to get anything to do with >> E.164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It's not = the >> appropriate query mechanism, and it has a golden root problem. I = remember >> well the DNS guys questioning whether DNS was the right protocol when = we >> started ENUM. We were so sure it was. It was a mistake then, and it = is >> now. >>=20 >> Let's learn from that and stay away from DNS. >>=20 >> We need a query with TN and service that returns either some form of = service >> provider id/service URL and/or some form of route. I personally = think that >> it would be best to keep route separate from service provider id/URL = because >> I do think the user controls that part of the record while the SP = controls >> the route. >>=20 >> Brian >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 >=20 From nobody Mon Oct 20 09:41:02 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9D41A8722 for ; Mon, 20 Oct 2014 09:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=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 Hvx2CT0v7lgU for ; Mon, 20 Oct 2014 09:40:58 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id C42271A87D0 for ; Mon, 20 Oct 2014 09:27:56 -0700 (PDT) Received: (qmail 23777 invoked by uid 0); 20 Oct 2014 16:27:54 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy8.mail.unifiedlayer.com with SMTP; 20 Oct 2014 16:27:54 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 5aSx1p00g1MNPNq01aT0jb; Mon, 20 Oct 2014 16:27:01 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8A7brI4kjU8C6ETGAX3PRdgeao0=:19 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=HLLxP2VMAAAA:8 a=4GpaQDp7AAAA:8 a=48vgC7mUAAAA:8 a=A1X0JdhQAAAA:8 a=FhcFriM2FFzrq-Ex2PIA:9 a=yk-5rFc0JeI-Teah:21 a=fyK6PUYj4Sqr7lR3:21 a=wPNLvfGTeEIA:10 a=-zy3ex45pM4A:10 a=FdVBEsWhMeQA:10 a=lZB815dzVvQA:10 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:CC:To:From:Subject:Date; bh=EMvTPJJfWw4YijFeSlSf2HL68wLKsFnbf/aO0XLDc1I=; b=Pu2U5z1r5yJ2u5Oh2DORW0mHxibKu7DH6mLDOOqCY7TrAbDZWuEMMlkwflSAxP5h8Q5s2UsRXjKDNSBnF6WDouwyUFWFS8cT4z2ChRac6lqQxyC/TlB7likHPvFYCPGf; Received: from [72.66.64.164] (port=53349 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XgFnN-0005dk-TB; Mon, 20 Oct 2014 10:26:58 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Mon, 20 Oct 2014 12:26:52 -0400 From: Richard Shockey To: Brian Rosen , Douglas Ranalli Message-ID: Thread-Topic: [Modern] Services References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> In-Reply-To: <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/eCP6-3HTmqFmr43adFCd-SXmfxc Cc: "Gorman, Pierce A \[NTK\]" , modern@ietf.org, "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:41:00 -0000 =8B On 10/20/14, 12:06 PM, "Brian Rosen" wrote: >I like the way you are thinking. > >I do want to pick out your number 3. > >It may very well be that what we want is a SPID. I would like to figure >out if SPID is actually what we want before we start going down the path >of creating a new identifier. > >You want a SPID when an entity doing a query has some sort of database >that can translate SPID to something else. A good example might be you >have peering relationships with some SPs, but for others, you use a >transit provider. You have a database by SPID of which provider you send >a call to. I like that example because you would not put that >information in some common database - it=B9s local to you. > >But, do we need an SPID that is different from a domain name? Domain >Names are unique, so that=B9s one thing we need. They are easy to create, >and we already have a management process. I think the downside is that >not all domains are SPIDs, and we might need to know the difference. >Another one is because they are cheap, they may proliferate in ways >detrimental to maintaining things like routing databases. > >But, as a straw man, what is wrong with domain name as SPID? Security .. Topology hiding.. This is not the DNS as you point out. There are lots of other reasons for this. But I=B9m pretty sure a name space could be created at minimal industry cost. > >Brian > >> On Oct 20, 2014, at 11:36 AM, Douglas Ranalli >>wrote: >>=20 >> Henning and Brian, >>=20 >> Great discussion over the past week. There might be some value in >>breaking >> the discussion down into separate distinct concepts. Here's a strawman >>to >> consider: >>=20 >> - Concept-1: Number Allocation: Today, numbers are assigned as >>code-ranges >> to licensed carriers. The group has already explored several possible >> enhancements. Seems like the direction is to move towards more granular >> allocation of numbers (perhaps TN specific) to a broader set of industry >> players (not just licensed carriers). Lots of interesting policy >>decisions >> here that eventually need to be reflected in an underlying >>implementation. >>=20 >>=20 >> - Concept-2: Multiple SPs Per TN: The concept of multiple-services >> associated with a TN seems like an important advancement from our >>current >> telephony architecture. The group has explored this from several >>angles. >> Key policy issue is to guarantee a user's right to select more than one >>SP >> to provide services associated with the single TN. Key technology >>issue is >> to define how multiple services are discovered. Brian, your note below >> proposes a query for "TN and service". I like the idea of being able >>to ask >> for a single "service" but I think a mechanism is necessary to discover >>all >> of the services associated with a TN as well. >>=20 >> - Concept-3: Service Provider ID: We've seen from experience that the >> minimum requirement for reaching a given service associated with a >>given TN >> is identifying some type of unique "service-provider ID" associated >>with the >> service. I draw this out as a separate concept because it involves >> agreement on a global naming convention that works for licensed >> carriers/operators, OTT providers, enterprises, etc. We're still >>missing a >> globally unique service-provider-ID mechanism that can be managed by the >> industry. I see value in separating the concept of service-provider >> discovery from route-discovery. >>=20 >> - Concept-4: Routing: The final step is to establish a >>connection/session >> with the destination service-provider. I agree with Brian that the >> mechanism for defining the route is separate from the mechanism for >>defining >> the service-provider-ID. The user selects a service-provider for a >>given >> service. The originating and terminating service-providers both have a >>role >> to play in defining if/when/how to route to a given service. Current >> experience with SIP interconnect suggests that every originating SP can >> define its own local routing policy for reaching a given destination >> service. The solution involves bilateral interconnect discussions that >>are >> slow but it works. Alternatively we can explore a dynamic >>route-discovery >> mechanism that provides for destination-specific entry-point discovery >>that >> might vary by origin. I like the idea of dynamic discovery because it >> aligns with the general trend towards mobility in all forms of >> communication.=20 >>=20 >> Doug >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >> Schulzrinne >> Sent: Monday, October 20, 2014 9:58 AM >> To: Brian Rosen >> Cc: Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, PENN L; Richard >>Shockey >> Subject: Re: [Modern] Services >>=20 >> I suspect we're talking past each other. I'm not advocating a "golden >>root" >> or anything that looks like ENUM number-based mapping. As a strawman, >> consider a JSON response within the MODERN context to a query for a >>phone >> number, returning for you >>=20 >> "media": "myphone.brianrosen.net" >>=20 >> with myphone.brianrosen.net >>=20 >> resolving to >>=20 >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>=20 >>=20 >> I assume we don't want to put IP addresses directly into the response, >>so >> DNS enters the picture at some point. >>=20 >> The alternative is to use the SRV or NAPTR service field (here, >>_sip._tcp) >> directly in the MODERN response. I can see advantages to both. >>=20 >> Henning >>=20 >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>modern@ietf.org >> Subject: Re: [Modern] Services >>=20 >> I really would like to get away from DNS entirely. We can reuse >>concepts, >> but I think DNS is not the appropriate way to get anything to do with >> E.164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It's not the >> appropriate query mechanism, and it has a golden root problem. I >>remember >> well the DNS guys questioning whether DNS was the right protocol when we >> started ENUM. We were so sure it was. It was a mistake then, and it is >> now. >>=20 >> Let's learn from that and stay away from DNS. >>=20 >> We need a query with TN and service that returns either some form of >>service >> provider id/service URL and/or some form of route. I personally think >>that >> it would be best to keep route separate from service provider id/URL >>because >> I do think the user controls that part of the record while the SP >>controls >> the route. >>=20 >> Brian >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 > From nobody Mon Oct 20 09:46:55 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F041A88C2 for ; Mon, 20 Oct 2014 09:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=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 ZZK2RTLGko0L for ; Mon, 20 Oct 2014 09:46:52 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E7AA71A0A6A for ; Mon, 20 Oct 2014 09:33:11 -0700 (PDT) Received: (qmail 13156 invoked by uid 0); 20 Oct 2014 16:33:11 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 20 Oct 2014 16:33:11 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 5UY51p00p1MNPNq01UY8LH; Mon, 20 Oct 2014 10:32:15 -0600 X-Authority-Analysis: v=2.1 cv=Tr912lnh c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8A7brI4kjU8C6ETGAX3PRdgeao0=:19 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=zQP7CpKOAAAA:8 a=5Mz7otzJAAAA:8 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a=4GpaQDp7AAAA:8 a=A1X0JdhQAAAA:8 a=ZFZavLYDc-L7oiarwBIA:9 a=D-Z60MHr_VOU_Ksg:21 a=ZEEDrK0SPmmSq2c6:21 a=wPNLvfGTeEIA:10 a=Hz7IrDYlS0cA:10 a=-zy3ex45pM4A:10 a=lZB815dzVvQA:10 a=FdVBEsWhMeQA:10 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:CC:To:From:Subject:Date; bh=eFPMvMzPJy52jLk5+qSA4CaDH1CmoeFdRh3ERBUn8tA=; b=OWnzEw7M1un/t7lwRujv5XkYkIvIe6sqqeN11xc0TPNozccArE267/N2bHz6k4LQ7pi0erMLMbYI/p1dXKdEwJWLaoivxaEK3CAdYAHfa7swFO5PAdWWTXRd4Hv0VBVn; Received: from [72.66.64.164] (port=53350 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XgFsM-0002e1-6Q; Mon, 20 Oct 2014 10:32:06 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Mon, 20 Oct 2014 12:32:01 -0400 From: Richard Shockey To: "PFAUTZ, PENN L" , Brian Rosen , Douglas Ranalli Message-ID: Thread-Topic: [Modern] Services References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741DB8@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605741DB8@MISOUT7MSGUSRDD.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/i-cstSPCNMXRzjo4eU0MyeBB7iM Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:46:54 -0000 Penn based on my personal conversations on this matter the RIR=B9s would do it. It sits front and center to their ongoing mission. Its just that it would take work to formulate the proposals some informational RFC=B9s and go through the various open multi stake holder consensus =8Aetc that they all have. Travel budgets etc. Its a matter of commitment. On 10/20/14, 12:24 PM, "PFAUTZ, PENN L" wrote: >Brian: >The i3 Forum did a bit of work on SPID (see >http://i3forum.org/i3forum-global-spid-specifications-release-1-may-2011/) >There were some parties that wanted a numeric identifier, but as with >ENUM, the biggest issues were not technical but business in terms of >getting agreement on who would administer SPID. I took a run at a number >of alternatives, IANA, ITU, RIR, without really getting anywhere. There >was some suggestion the GSMA might step up. >We do want something global. > >Penn > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Monday, October 20, 2014 12:07 PM >To: Douglas Ranalli >Cc: Henning Schulzrinne; Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, >PENN L; Richard Shockey >Subject: Re: [Modern] Services > >I like the way you are thinking. > >I do want to pick out your number 3. > >It may very well be that what we want is a SPID. I would like to figure >out if SPID is actually what we want before we start going down the path >of creating a new identifier. > >You want a SPID when an entity doing a query has some sort of database >that can translate SPID to something else. A good example might be you >have peering relationships with some SPs, but for others, you use a >transit provider. You have a database by SPID of which provider you send >a call to. I like that example because you would not put that >information in some common database - it=B9s local to you. > >But, do we need an SPID that is different from a domain name? Domain >Names are unique, so that=B9s one thing we need. They are easy to create, >and we already have a management process. I think the downside is that >not all domains are SPIDs, and we might need to know the difference. >Another one is because they are cheap, they may proliferate in ways >detrimental to maintaining things like routing databases. > >But, as a straw man, what is wrong with domain name as SPID? > >Brian > >> On Oct 20, 2014, at 11:36 AM, Douglas Ranalli >>wrote: >>=20 >> Henning and Brian, >>=20 >> Great discussion over the past week. There might be some value in >>breaking >> the discussion down into separate distinct concepts. Here's a strawman >>to >> consider: >>=20 >> - Concept-1: Number Allocation: Today, numbers are assigned as >>code-ranges >> to licensed carriers. The group has already explored several possible >> enhancements. Seems like the direction is to move towards more granular >> allocation of numbers (perhaps TN specific) to a broader set of industry >> players (not just licensed carriers). Lots of interesting policy >>decisions >> here that eventually need to be reflected in an underlying >>implementation. >>=20 >>=20 >> - Concept-2: Multiple SPs Per TN: The concept of multiple-services >> associated with a TN seems like an important advancement from our >>current >> telephony architecture. The group has explored this from several >>angles. >> Key policy issue is to guarantee a user's right to select more than one >>SP >> to provide services associated with the single TN. Key technology >>issue is >> to define how multiple services are discovered. Brian, your note below >> proposes a query for "TN and service". I like the idea of being able >>to ask >> for a single "service" but I think a mechanism is necessary to discover >>all >> of the services associated with a TN as well. >>=20 >> - Concept-3: Service Provider ID: We've seen from experience that the >> minimum requirement for reaching a given service associated with a >>given TN >> is identifying some type of unique "service-provider ID" associated >>with the >> service. I draw this out as a separate concept because it involves >> agreement on a global naming convention that works for licensed >> carriers/operators, OTT providers, enterprises, etc. We're still >>missing a >> globally unique service-provider-ID mechanism that can be managed by the >> industry. I see value in separating the concept of service-provider >> discovery from route-discovery. >>=20 >> - Concept-4: Routing: The final step is to establish a >>connection/session >> with the destination service-provider. I agree with Brian that the >> mechanism for defining the route is separate from the mechanism for >>defining >> the service-provider-ID. The user selects a service-provider for a >>given >> service. The originating and terminating service-providers both have a >>role >> to play in defining if/when/how to route to a given service. Current >> experience with SIP interconnect suggests that every originating SP can >> define its own local routing policy for reaching a given destination >> service. The solution involves bilateral interconnect discussions that >>are >> slow but it works. Alternatively we can explore a dynamic >>route-discovery >> mechanism that provides for destination-specific entry-point discovery >>that >> might vary by origin. I like the idea of dynamic discovery because it >> aligns with the general trend towards mobility in all forms of >> communication.=20 >>=20 >> Doug >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >> Schulzrinne >> Sent: Monday, October 20, 2014 9:58 AM >> To: Brian Rosen >> Cc: Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, PENN L; Richard >>Shockey >> Subject: Re: [Modern] Services >>=20 >> I suspect we're talking past each other. I'm not advocating a "golden >>root" >> or anything that looks like ENUM number-based mapping. As a strawman, >> consider a JSON response within the MODERN context to a query for a >>phone >> number, returning for you >>=20 >> "media": "myphone.brianrosen.net" >>=20 >> with myphone.brianrosen.net >>=20 >> resolving to >>=20 >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>=20 >>=20 >> I assume we don't want to put IP addresses directly into the response, >>so >> DNS enters the picture at some point. >>=20 >> The alternative is to use the SRV or NAPTR service field (here, >>_sip._tcp) >> directly in the MODERN response. I can see advantages to both. >>=20 >> Henning >>=20 >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>modern@ietf.org >> Subject: Re: [Modern] Services >>=20 >> I really would like to get away from DNS entirely. We can reuse >>concepts, >> but I think DNS is not the appropriate way to get anything to do with >> E.164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It's not the >> appropriate query mechanism, and it has a golden root problem. I >>remember >> well the DNS guys questioning whether DNS was the right protocol when we >> started ENUM. We were so sure it was. It was a mistake then, and it is >> now. >>=20 >> Let's learn from that and stay away from DNS. >>=20 >> We need a query with TN and service that returns either some form of >>service >> provider id/service URL and/or some form of route. I personally think >>that >> it would be best to keep route separate from service provider id/URL >>because >> I do think the user controls that part of the record while the SP >>controls >> the route. >>=20 >> Brian >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >>=20 > From nobody Mon Oct 20 09:49:48 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC301A892C for ; Mon, 20 Oct 2014 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 c_i9_uNytEUa for ; Mon, 20 Oct 2014 09:49:46 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD651A89B4 for ; Mon, 20 Oct 2014 09:35:48 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so3963208qcx.21 for ; Mon, 20 Oct 2014 09:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=/0OX0ijsb3e9KBfdHnNObeFtSfhNPC/uJ02h5XI2OFI=; b=a2TmTf0rX+jx8/INMbSDaP3FRFDd7DNeGtcBabXOiKZ6JjHg+0DcFXJ5wMaIGouGJA RvhOM0LhIEQaZXrngbaxWAOluG8MCf/RmaubybStbbmJNv1lfp8XqMBHsaJfUUgtN1q9 yQfikGFcp8LYmeGPz4PjICes0N1Vk9S21WttuNBehbFSsfzlNC9IOsgjch2IsJ3KOv8j 0A0su2JA3XGB2HI/7t1pxqkheglVDeKfxH/BhskT9AHNlmgS44ORJszY2XZ5GsNg5ytG FxvzrCuAMcUiKiqaPNL2zqOsixZNIgajDnFRMDEYcOFTS64LKogL+7n7P+mIg9WlKpIm OwwQ== X-Gm-Message-State: ALoCoQn8NDU0EJm2rBUfBkHLiyyCcCmcQ9o1fJyo1l6RC352N2xLaDhdorGC7bAhkEGCyRsZA6YK X-Received: by 10.224.79.146 with SMTP id p18mr36099808qak.67.1413822947270; Mon, 20 Oct 2014 09:35:47 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id w9sm8300996qaw.9.2014.10.20.09.35.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 09:35:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: Date: Mon, 20 Oct 2014 12:35:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> To: Richard Shockey X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/DFpgqoYV8wK3VTGW9I3l8Gskfbw Cc: modern@ietf.org, "Gorman, Pierce A \[NTK\]" , Douglas Ranalli , "PFAUTZ, PENN L" , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:49:47 -0000 > Security .. Topology hiding.. This is not the DNS as you point out. = There > are lots of other reasons for this. But I=C4=85m pretty sure a name = space could > be created at minimal industry cost. >=20 Possibly you are mistaking what I=E2=80=99m suggesting. I=E2=80=99m suggesting that rather than creating a new identifier, = let=E2=80=99s say it was numeric, administered by someone, that we use a = string that just happens to be the same as a domain owned by the SP, = administered by the existing DNS registrars. I=E2=80=99m not suggesting that there is anything in the DNS entry for = that domain that we=E2=80=99re using for identification. I=E2=80=99m = just suggesting that the string =E2=80=9Catt.net=E2=80=9D is a very fine = SPID. AT&T already owns it. We have an acceptable administrator for = it. It=E2=80=99s globally unique. =E2=80=9Cbroadband.com=E2=80=9D is = perfectly fine. =E2=80=9Cbrianrosen.net=E2=80=9D is also okay. It=E2=80=99= s a globally unique string, owned by the =E2=80=9CService Provider=E2=80=9D= , capable of being used whenever a lookup in a database that needs some = column for =E2=80=9Cservice provider id=E2=80=9D. What else do we need? Brian From nobody Mon Oct 20 09:50:00 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5581A8BB0 for ; Mon, 20 Oct 2014 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=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 ySC0RfHrZkGV for ; Mon, 20 Oct 2014 09:49:56 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A39181A906A for ; Mon, 20 Oct 2014 09:35:58 -0700 (PDT) Received: (qmail 11958 invoked by uid 0); 20 Oct 2014 16:24:30 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 20 Oct 2014 16:24:30 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 5aPT1p00U1MNPNq01aPWFR; Mon, 20 Oct 2014 16:23:39 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8A7brI4kjU8C6ETGAX3PRdgeao0=:19 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=4GpaQDp7AAAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=A1X0JdhQAAAA:8 a=96rrx1-UHqep21-XXv0A:9 a=AApEo5zfINAIMbuU:21 a=73xMjDM7VW-G-fNA:21 a=wPNLvfGTeEIA:10 a=FdVBEsWhMeQA:10 a=lZB815dzVvQA:10 a=-zy3ex45pM4A:10 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:CC:To:From:Subject:Date; bh=Oa1XieTpP7PwhBNoH4OrpkQmH7eofrGPJjFKFKKXds8=; b=NdXpMnFpBIYySyNgflZbmgVgWX/mITesTVbaT4T+EPANF0BO5C9bpYe41u9lBKzVv8rLSz08AkKcocWnslmZW++aCNMrxsGWo4ZIHivQAz0k9/cMHCwVaKxlljLqzofE; Received: from [72.66.64.164] (port=53346 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XgFjz-0001g7-Uv; Mon, 20 Oct 2014 10:23:28 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Mon, 20 Oct 2014 12:23:22 -0400 From: Richard Shockey To: Douglas Ranalli , 'Henning Schulzrinne' , 'Brian Rosen' Message-ID: Thread-Topic: [Modern] Services References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> In-Reply-To: <00fa01cfec7b$9ccfa460$d66eed20$@com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Td-kg9jb4_J8nbGbWf_e6VXUjjk Cc: "'Gorman, Pierce A \[NTK\]'" , modern@ietf.org, "'PFAUTZ, PENN L'" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:49:58 -0000 In Line .. On 10/20/14, 11:36 AM, "Douglas Ranalli" wrote: >Henning and Brian, > >Great discussion over the past week. There might be some value in >breaking >the discussion down into separate distinct concepts. Here's a strawman to >consider: > >- Concept-1: Number Allocation: Today, numbers are assigned as >code-ranges >to licensed carriers. The group has already explored several possible >enhancements. Seems like the direction is to move towards more granular >allocation of numbers (perhaps TN specific) to a broader set of industry >players (not just licensed carriers). Lots of interesting policy >decisions >here that eventually need to be reflected in an underlying implementation. RS> +1 Though I think given realities single digit allocations over time is the preferred end goal also flatten the namespace by requiring 10 digit dialing that would ultimately give us national number portability or essentially one number for life ( if you stay in North America). I can hear the whining from 202 Area Code holders but NYC did a overlay and the Republic still stands.(see the Seinfeld episode) > >- Concept-3: Service Provider ID: We've seen from experience that the >minimum requirement for reaching a given service associated with a given >TN >is identifying some type of unique "service-provider ID" associated with >the >service. I draw this out as a separate concept because it involves >agreement on a global naming convention that works for licensed >carriers/operators, OTT providers, enterprises, etc. We're still missing >a >globally unique service-provider-ID mechanism that can be managed by the >industry. I see value in separating the concept of service-provider >discovery from route-discovery. RS> Doug I=B9m glad you brought this up. It has come up in several contexts and I personally ran a couple of memos around the industry to look into this. Our international i3forum friends have had this problem for some time. One idea was to create a G-SPID. To hold costs in line it could be administered similar to AS numbers by the RIR=B9s. I talked to ARIN and RIPE about this and they were willing if the communities would go through the process and put together the proposals. There was a very very strong desire within the industry NOT to go to Geneva about this, for obvious reasons. We know US carriers use the NECA OCN codes now but that that is not going to hold once we see further progress on International SIP Interconection. >=20 > >- Concept-4: Routing: The final step is to establish a connection/session >with the destination service-provider. I agree with Brian that the >mechanism for defining the route is separate from the mechanism for >defining >the service-provider-ID. The user selects a service-provider for a given >service. The originating and terminating service-providers both have a >role >to play in defining if/when/how to route to a given service. Current >experience with SIP interconnect suggests that every originating SP can >define its own local routing policy for reaching a given destination >service. The solution involves bilateral interconnect discussions that are >slow but it works. Alternatively we can explore a dynamic route-discovery >mechanism that provides for destination-specific entry-point discovery >that >might vary by origin. I like the idea of dynamic discovery because it >aligns with the general trend towards mobility in all forms of >communication.=20 RS> An arguments can be made that the terminating service provider wants more say in this than we have now. Its the entire Determinate Response issue that we used Kaplan source URI to overcome in ENUM generally but needs to be completely reimagined in this new environment. How the service is routed is based on who is asking the question and from where. > >Doug > > =20 > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >Schulzrinne >Sent: Monday, October 20, 2014 9:58 AM >To: Brian Rosen >Cc: Gorman, Pierce A [NTK]; modern@ietf.org; PFAUTZ, PENN L; Richard >Shockey >Subject: Re: [Modern] Services > >I suspect we're talking past each other. I'm not advocating a "golden >root" >or anything that looks like ENUM number-based mapping. As a strawman, >consider a JSON response within the MODERN context to a query for a phone >number, returning for you > >"media": "myphone.brianrosen.net" > >with myphone.brianrosen.net > >resolving to > >_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. > > >I assume we don't want to put IP addresses directly into the response, so >DNS enters the picture at some point. > >The alternative is to use the SRV or NAPTR service field (here, _sip._tcp) >directly in the MODERN response. I can see advantages to both. > >Henning > >________________________________________ >From: Brian Rosen [br@brianrosen.net] >Sent: Monday, October 20, 2014 9:51 AM >To: Henning Schulzrinne >Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >modern@ietf.org >Subject: Re: [Modern] Services > >I really would like to get away from DNS entirely. We can reuse concepts, >but I think DNS is not the appropriate way to get anything to do with >E.164s. >ENUM was a mistake, and one of the mistakes was using DNS. It's not the >appropriate query mechanism, and it has a golden root problem. I remember >well the DNS guys questioning whether DNS was the right protocol when we >started ENUM. We were so sure it was. It was a mistake then, and it is >now. > >Let's learn from that and stay away from DNS. > >We need a query with TN and service that returns either some form of >service >provider id/service URL and/or some form of route. I personally think >that >it would be best to keep route separate from service provider id/URL >because >I do think the user controls that part of the record while the SP controls >the route. > >Brian >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > From nobody Mon Oct 20 09:56:51 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EDF1A8932 for ; Mon, 20 Oct 2014 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PENIS1=3.592, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Hjc7b6CBzZSS for ; Mon, 20 Oct 2014 09:56:50 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C961A8ACF for ; Mon, 20 Oct 2014 09:43:07 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id b9b35445.2ae479234940.3195484.00-2448.8998319.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 20 Oct 2014 16:43:07 +0000 (UTC) X-MXL-Hash: 54453b9b1ca11243-29b989447aefcf773de22c378ffa34dddeecd4c1 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 89b35445.0.3195443.00-2277.8998198.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 20 Oct 2014 16:43:07 +0000 (UTC) X-MXL-Hash: 54453b9b6d145772-6bc17b4b5e8c0a38845856d4379fd09d0930cafb 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 s9KGh3m5029073; Mon, 20 Oct 2014 12:43:04 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9KGgoiC028781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 12:42:54 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 20 Oct 2014 16:42:31 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 12:42:31 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Richard Shockey Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegAATOQCAAFVQAP//xSJwAAAdV0A= Date: Mon, 20 Oct 2014 16:42:30 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605741E04@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=Ikc] X-AnalysisOut: [TkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=8A7brI4kj] X-AnalysisOut: [U8C6ETGAX3PRdgeao0=:19 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=HZJGGiqLAAAA:8 a=yNrENd7nAAAA:8 a=mMoLFxFWeDUarnNxmQ4A:9 ] X-AnalysisOut: [a=QEXdDO2ut3YA:10 a=fecXxnoC4hcA:10 a=yKQWi9d4ie8A:10 a=m3] X-AnalysisOut: [_RC9WD6_UA:10 a=-zy3ex45pM4A:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/FRAw7N4YPugZ_CBGbxPu84hYKfQ Cc: "modern@ietf.org" , "Gorman, Pierce A \[NTK\]" , Douglas Ranalli , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:56:50 -0000 U28gdG8gYmUgY2xlYXIsDQpZb3UncmUgcHJvcG9zaW5nIHRoYXQgYW4gU1AgZGVzaWduYXRlIG9u ZSBvciBtb3JlIG9mIHRoZWlyIGRvbWFpbiBuYW1lcyBhcyBTUElEcyBhbmQgdGhlc2UgU1BJRHMg d291bGQgdGhlbiBiZSB1c2VkIGluIHRoZSBFLjE2NCBSZWdpc3RyeShpZXMpPw0KDQpTaW5jZSBJ IHdhcyBub3Qgb25lIG9mIHRob3NlIGZvbGtzIHRoYXQgd2FudCB0byBkbyBwcmVmaXhpbmcgKG9u ZSBvZiB0aGUgaTMgZHJpdmVycyBmb3IgbnVtZXJpYykgSSB0aGluayBJIGNvdWxkIGxpdmUgd2l0 aCB0aGlzLiBJdCBkb2VzIG1lZXQgdGhlIGNyaXRlcmlhIG9mIGJlaW5nIGF2YWlsYWJsZSB0byBh bGwgcG90ZW50aWFsIFNQcywgdW5saWtlLCBzYXksIE5FQ0Egc3R1ZmYuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4u bmV0XSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMCwgMjAxNCAxMjozNiBQTQ0KVG86IFJpY2hh cmQgU2hvY2tleQ0KQ2M6IERvdWdsYXMgUmFuYWxsaTsgSGVubmluZyBTY2h1bHpyaW5uZTsgR29y bWFuLCBQaWVyY2UgQSBbTlRLXTsgbW9kZXJuQGlldGYub3JnOyBQRkFVVFosIFBFTk4gTA0KU3Vi amVjdDogUmU6IFtNb2Rlcm5dIFNlcnZpY2VzDQoNCj4gU2VjdXJpdHkgLi4gVG9wb2xvZ3kgaGlk aW5nLi4gVGhpcyBpcyBub3QgdGhlIEROUyBhcyB5b3UgcG9pbnQgb3V0LiBUaGVyZQ0KPiBhcmUg bG90cyBvZiBvdGhlciByZWFzb25zIGZvciB0aGlzLiBCdXQgScSFbSBwcmV0dHkgc3VyZSBhIG5h bWUgc3BhY2UgY291bGQNCj4gYmUgY3JlYXRlZCBhdCBtaW5pbWFsIGluZHVzdHJ5IGNvc3QuDQo+ IA0KDQpQb3NzaWJseSB5b3UgYXJlIG1pc3Rha2luZyB3aGF0IEnigJltIHN1Z2dlc3RpbmcuDQoN CknigJltIHN1Z2dlc3RpbmcgdGhhdCByYXRoZXIgdGhhbiBjcmVhdGluZyBhIG5ldyBpZGVudGlm aWVyLCBsZXTigJlzIHNheSBpdCB3YXMgbnVtZXJpYywgYWRtaW5pc3RlcmVkIGJ5IHNvbWVvbmUs IHRoYXQgd2UgdXNlIGEgc3RyaW5nIHRoYXQganVzdCBoYXBwZW5zIHRvIGJlIHRoZSBzYW1lIGFz IGEgZG9tYWluIG93bmVkIGJ5IHRoZSBTUCwgYWRtaW5pc3RlcmVkIGJ5IHRoZSBleGlzdGluZyBE TlMgcmVnaXN0cmFycy4NCg0KSeKAmW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB0aGVyZSBpcyBhbnl0 aGluZyBpbiB0aGUgRE5TIGVudHJ5IGZvciB0aGF0IGRvbWFpbiB0aGF0IHdl4oCZcmUgdXNpbmcg Zm9yIGlkZW50aWZpY2F0aW9uLiAgSeKAmW0ganVzdCBzdWdnZXN0aW5nIHRoYXQgdGhlIHN0cmlu ZyDigJxhdHQubmV04oCdIGlzIGEgdmVyeSBmaW5lIFNQSUQuICBBVCZUIGFscmVhZHkgb3ducyBp dC4gIFdlIGhhdmUgYW4gYWNjZXB0YWJsZSBhZG1pbmlzdHJhdG9yIGZvciBpdC4gIEl04oCZcyBn bG9iYWxseSB1bmlxdWUuICDigJxicm9hZGJhbmQuY29t4oCdIGlzIHBlcmZlY3RseSBmaW5lLiAg 4oCcYnJpYW5yb3Nlbi5uZXTigJ0gaXMgYWxzbyBva2F5LiAgSXTigJlzIGEgZ2xvYmFsbHkgdW5p cXVlIHN0cmluZywgb3duZWQgYnkgdGhlIOKAnFNlcnZpY2UgUHJvdmlkZXLigJ0sIGNhcGFibGUg b2YgYmVpbmcgdXNlZCB3aGVuZXZlciBhIGxvb2t1cCBpbiBhIGRhdGFiYXNlIHRoYXQgbmVlZHMg c29tZSBjb2x1bW4gZm9yIOKAnHNlcnZpY2UgcHJvdmlkZXIgaWTigJ0uDQoNCldoYXQgZWxzZSBk byB3ZSBuZWVkPw0KDQpCcmlhbg0KDQoNCg0K From nobody Mon Oct 20 09:58:17 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F4B1A7009 for ; Mon, 20 Oct 2014 09:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham 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 wgi1QOz4ev6Q for ; Mon, 20 Oct 2014 09:58:13 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE021A1B4E for ; Mon, 20 Oct 2014 09:45:21 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so3663494qac.12 for ; Mon, 20 Oct 2014 09:45:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=xHO/qwi1YnR5cgk9kFaFrkgwz67qRcd9vABo89ZY22o=; b=TFO3zxMxD/vcTsmMzfH93imGtp3LIPEdMXTE2nKb2KeZ59j2nYne+dcSAW803/9PBJ rKSJJsx+2xOVgUSoCLIAQVQ+Z0lqit782f+EZLsaAtOEkHnWpTobfK8iMvrlTIIvYhQN 0gvgdCYUD14XFu0U6D3yCaefZqkUZM7SPhGL0l67xxohWXVAOgbHNJm8VE4j9gO2qkc4 fxOZZPGJJZRRF8eMkZwSTnsjjAjS9E7Eualb9OfFuwDahMe0VU6vQBLZWcLrFp56im9r tCYY07FEgx4zeh8r0bgfd4KDi5zbjJV71CO1moiYPkDVkgtYHO+2lS5LZnsWqgDNWGMS 4nLw== X-Gm-Message-State: ALoCoQmeLXeH/fWyYe1w4/WymECs47wsXt6cuPVsxSsl3Yyh3Xi23y80yAFYOO7uNxN1KXHHhk5N X-Received: by 10.140.86.135 with SMTP id p7mr36356361qgd.54.1413823519869; Mon, 20 Oct 2014 09:45:19 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 36sm8304365qgn.10.2014.10.20.09.45.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 09:45:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: <38726EDA2109264987B45E29E758C4D605741E04@MISOUT7MSGUSRDD.ITServices.sbc.com> Date: Mon, 20 Oct 2014 12:45:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741E04@MISOUT7MSGUSRDD.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/0KpjFaFD3SLcS0Um75hXGUfwUfA Cc: "modern@ietf.org" , "Gorman, Pierce A \[NTK\]" , Henning Schulzrinne , Douglas Ranalli , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:58:16 -0000 Yep, that=E2=80=99s my proposal. It requires a bit of care at the provider. They often have a zillion = domain names, and they have to choose which one(s) to use, and use them = consistently. But it=E2=80=99s really no more complex than managing any = other form of SPID. =20 Brian > On Oct 20, 2014, at 12:42 PM, PFAUTZ, PENN L wrote: >=20 > So to be clear, > You're proposing that an SP designate one or more of their domain = names as SPIDs and these SPIDs would then be used in the E.164 = Registry(ies)? >=20 > Since I was not one of those folks that want to do prefixing (one of = the i3 drivers for numeric) I think I could live with this. It does meet = the criteria of being available to all potential SPs, unlike, say, NECA = stuff. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Monday, October 20, 2014 12:36 PM > To: Richard Shockey > Cc: Douglas Ranalli; Henning Schulzrinne; Gorman, Pierce A [NTK]; = modern@ietf.org; PFAUTZ, PENN L > Subject: Re: [Modern] Services >=20 >> Security .. Topology hiding.. This is not the DNS as you point out. = There >> are lots of other reasons for this. But I=C4=85m pretty sure a name = space could >> be created at minimal industry cost. >>=20 >=20 > Possibly you are mistaking what I=E2=80=99m suggesting. >=20 > I=E2=80=99m suggesting that rather than creating a new identifier, = let=E2=80=99s say it was numeric, administered by someone, that we use a = string that just happens to be the same as a domain owned by the SP, = administered by the existing DNS registrars. >=20 > I=E2=80=99m not suggesting that there is anything in the DNS entry for = that domain that we=E2=80=99re using for identification. I=E2=80=99m = just suggesting that the string =E2=80=9Catt.net=E2=80=9D is a very fine = SPID. AT&T already owns it. We have an acceptable administrator for = it. It=E2=80=99s globally unique. =E2=80=9Cbroadband.com=E2=80=9D is = perfectly fine. =E2=80=9Cbrianrosen.net=E2=80=9D is also okay. It=E2=80=99= s a globally unique string, owned by the =E2=80=9CService Provider=E2=80=9D= , capable of being used whenever a lookup in a database that needs some = column for =E2=80=9Cservice provider id=E2=80=9D. >=20 > What else do we need? >=20 > Brian >=20 >=20 >=20 From nobody Mon Oct 20 11:22:21 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5178E1A8A7E for ; Mon, 20 Oct 2014 11:22:14 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 4TDD3MkWPya4 for ; Mon, 20 Oct 2014 11:22:09 -0700 (PDT) Received: from agamemnon.swishmail.com (agamemnon.swishmail.com [208.72.57.30]) (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 3EB831A1B0E for ; Mon, 20 Oct 2014 11:22:08 -0700 (PDT) Received: (qmail 53340 invoked by uid 89); 20 Oct 2014 18:22:04 -0000 Received: from unknown (HELO dranalliWin7) (dranalli@netnumber.com@75.150.73.57) by agamemnon.swishmail.com with ESMTPA; 20 Oct 2014 18:22:04 -0000 From: "Douglas Ranalli" To: "'Brian Rosen'" , "'PFAUTZ, PENN L'" References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741E04@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Date: Mon, 20 Oct 2014 14:22:03 -0400 Message-ID: <015301cfec92$bfcfca00$3f6f5e00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/shT8So+NC2VwHRmWE8XncNBoK0wADQx8g Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/modern/X2xfmuWCFbAATbikSdezvbk2FbM Cc: modern@ietf.org, 'Henning Schulzrinne' , "'Gorman, Pierce A \[NTK\]'" , 'Richard Shockey' Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:22:14 -0000 I agree that a globally unique domain name seems like a perfectly valid = implementation of a service-provider-ID (SPID) in the context of = identifying a destination service-provider for a communications service = associated with a TN.=20 Doug -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, October 20, 2014 12:45 PM To: PFAUTZ, PENN L Cc: Richard Shockey; Douglas Ranalli; Henning Schulzrinne; Gorman, = Pierce A [NTK]; modern@ietf.org Subject: Re: [Modern] Services Yep, that=E2=80=99s my proposal. It requires a bit of care at the provider. They often have a zillion = domain names, and they have to choose which one(s) to use, and use them = consistently. But it=E2=80=99s really no more complex than managing any = other form of SPID. =20 Brian > On Oct 20, 2014, at 12:42 PM, PFAUTZ, PENN L wrote: >=20 > So to be clear, > You're proposing that an SP designate one or more of their domain = names as SPIDs and these SPIDs would then be used in the E.164 = Registry(ies)? >=20 > Since I was not one of those folks that want to do prefixing (one of = the i3 drivers for numeric) I think I could live with this. It does meet = the criteria of being available to all potential SPs, unlike, say, NECA = stuff. >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, October 20, 2014 12:36 PM > To: Richard Shockey > Cc: Douglas Ranalli; Henning Schulzrinne; Gorman, Pierce A [NTK];=20 > modern@ietf.org; PFAUTZ, PENN L > Subject: Re: [Modern] Services >=20 >> Security .. Topology hiding.. This is not the DNS as you point out.=20 >> There are lots of other reasons for this. But I=C4=85m pretty sure a = name=20 >> space could be created at minimal industry cost. >>=20 >=20 > Possibly you are mistaking what I=E2=80=99m suggesting. >=20 > I=E2=80=99m suggesting that rather than creating a new identifier, = let=E2=80=99s say it was numeric, administered by someone, that we use a = string that just happens to be the same as a domain owned by the SP, = administered by the existing DNS registrars. >=20 > I=E2=80=99m not suggesting that there is anything in the DNS entry for = that domain that we=E2=80=99re using for identification. I=E2=80=99m = just suggesting that the string =E2=80=9Catt.net=E2=80=9D is a very fine = SPID. AT&T already owns it. We have an acceptable administrator for = it. It=E2=80=99s globally unique. =E2=80=9Cbroadband.com=E2=80=9D is = perfectly fine. =E2=80=9Cbrianrosen.net=E2=80=9D is also okay. = It=E2=80=99s a globally unique string, owned by the =E2=80=9CService = Provider=E2=80=9D, capable of being used whenever a lookup in a database = that needs some column for =E2=80=9Cservice provider id=E2=80=9D. >=20 > What else do we need? >=20 > Brian >=20 >=20 >=20 From nobody Mon Oct 20 11:42:37 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD251A19E7 for ; Mon, 20 Oct 2014 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MfDDQGGv_oQR for ; Mon, 20 Oct 2014 11:42:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8B61F1A1B92 for ; Mon, 20 Oct 2014 11:42:27 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9KIgElS001777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 13:42:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54455786.4030709@nostrum.com> Date: Mon, 20 Oct 2014 13:42:14 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian Rosen , "PFAUTZ, PENN L" References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741C6A@MISOUT7MSGUSRDD.ITServices.sbc.com> <5A5A8D56-1C89-4F9C-ACBD-6FB370CA019E@brianrosen.net> In-Reply-To: <5A5A8D56-1C89-4F9C-ACBD-6FB370CA019E@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/modern/tdVCVm5Js2KwBHFK1QKbwYRu3Uk Cc: Henning Schulzrinne , "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:42:32 -0000 Actually, I find Penn's final sentence here -- "I would also like to see some technical commonality with the management of other types of PUIDs" -- to be of particular interest. I think it would be reasonable to keep the mechanism open to inputs other than numbers, and to consider delegation models other than numeric prefixes. /a On 10/20/14 09:18, Brian Rosen wrote: > Agree. I think we’re thinking REST/json > > Brian > >> On Oct 20, 2014, at 10:16 AM, PFAUTZ, PENN L wrote: >> >> I don't want to rehash the history of ENUM and I recognize there are some tasks it doesn't do well. I will, however, be skeptical of any one-off protocol for managing E.164 public user identities. I would expect that, like ENUM, whatever we come up with will be built on some more general protocol. I would also like to see some technical commonality with the management of other types of PUIDs. >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.org >> Subject: Re: [Modern] Services >> >> I really would like to get away from DNS entirely. We can reuse concepts, but I think DNS is not the appropriate way to get anything to do with E.164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It's not the appropriate query mechanism, and it has a golden root problem. I remember well the DNS guys questioning whether DNS was the right protocol when we started ENUM. We were so sure it was. It was a mistake then, and it is now. >> >> Let's learn from that and stay away from DNS. >> >> We need a query with TN and service that returns either some form of service provider id/service URL and/or some form of route. I personally think that it would be best to keep route separate from service provider id/URL because I do think the user controls that part of the record while the SP controls the route. >> >> Brian >> >>> On Oct 19, 2014, at 8:38 PM, Henning Schulzrinne wrote: >>> >>> This isn't *that* new, although obviously at a new scale. For example, there are many domain-specific URN schemes (e.g., DOIs for science publications) that are assigned outside ICANN control, but interact with DNS. >>> >>> We already have very basic mapping from numbers to domain names or IP addresses in the existing databases (and most certainly in the VRS numbering database), so this is not fundamentally new even for phone numbers. >>> >>> Besides the who-won't-like-it question, we already have a number space not managed by carriers, namely 800#. They illustrate to some extent that this can work technically, but preventing hoarding may require more scalable mechanisms than relying on kicking misbehaving entities out of the club. >>> >>> Thus, as a strawman, I could picture that the number record returned by a query returns (optionally) a domain name, resolved via DNS SRV or NAPTR as the next step. This allows various combinations of managed-by-carrier and managed-by-end user, depending on who gets to manage the DNS entry and who gets to manage the number record. This then becomes a policy knob, beyond the MODERN discussion. >>> >>> ________________________________________ >>> From: Richard Shockey [richard@shockey.us] >>> Sent: Saturday, October 18, 2014 8:30 PM >>> To: Henning Schulzrinne; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; Brian Rosen >>> Cc: modern@ietf.org >>> Subject: Re: [Modern] Services >>> >>> In general I¹d agree that a phone number is essentially a domain in the >>> classic theory of the abstraction of naming and addressing. That domain >>> should be consumer enterprise centric and carriers will ultimately IMHO >>> manage that service but I can also see the classic resistance of service >>> providers to the larger issue of number administration by consumers etc. >>> >>> We¹ve seen number administration become a classic barrier to entry for >>> competitors. I can site cases if anyone is interested. >>> >>> But the larger thrust here is something more interesting. What is the >>> real alternative to DNS for different classes of names outside the ICANN >>> model. Istnt that what we are talking about? We accept and create a >>> model of resolution of one class of names E.164 totally outside the ICANN >>> model of administration. >>> >>> NGN ENUM not using DNS preserving the traditional rights of nation states >>> to administer their portions of the numbering plan? >>> >>> I¹m just thinking. >>> > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Mon Oct 20 18:35:08 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797161ACE3A for ; Mon, 20 Oct 2014 18:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 zlDDUhKllK7z for ; Mon, 20 Oct 2014 18:35:04 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 7868D1ACE37 for ; Mon, 20 Oct 2014 18:35:03 -0700 (PDT) Received: from pps.filterd (m0049367.ppops.net [127.0.0.1]) by m0049367.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s9L1Udma032158; Mon, 20 Oct 2014 21:34:59 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049367.ppops.net-0018ba01. with ESMTP id 1q59kq8ca4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 20 Oct 2014 21:34:58 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.97]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 21:34:58 -0400 From: "Peterson, Jon" To: Brian Rosen , "PFAUTZ, PENN L" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegAATOQCAAFVQAIAABaUAgAACegCAAAHkAIAAAMeAgAAenYA= Date: Tue, 21 Oct 2014 01:34:57 +0000 Message-ID: References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <00fa01cfec7b$9ccfa460$d66eed20$@com> <11E545E6-90BB-4F71-A3CD-3A47DCA04FB6@brianrosen.net> <38726EDA2109264987B45E29E758C4D605741E04@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [192.168.129.88] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <527DF03494B295459035B3FBCCE77E30@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7597 signatures=670556 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=8.60422844084496e-15 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410210016 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/ogeTDFv09tyiU_sI_sNgS-S6jqk Cc: Douglas Ranalli , "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Richard Shockey , Henning Schulzrinne Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 01:35:06 -0000 If history shows us anything, it's that we need to be versatile in the identifiers we accommodate. While ideally, we could standardize on some single thing, different contexts seem to consistently require different elements. This is why I think it's still premature to worry too much about whether the key is in the DNS, or ENUM, or DIAMETER, or whatever. The exercise I think we need is to tabulate what kinds of data authorities want to provision associated with identifiers, and what kinds of questions network elements of various types want to ask about those identifiers. I suspect SPIDs, DNS names, and many other elements will ultimately be at play. We will need a framework to enable that, and the nature of the framework will come into focus as we better understand those practical needs of protocols and services.=20 Jon Peterson Neustar, Inc. On 10/20/14, 9:45 AM, "Brian Rosen" wrote: >Yep, that's my proposal. > >It requires a bit of care at the provider. They often have a zillion >domain names, and they have to choose which one(s) to use, and use them >consistently. But it's really no more complex than managing any other >form of SPID. =20 > >Brian > >> On Oct 20, 2014, at 12:42 PM, PFAUTZ, PENN L wrote: >>=20 >> So to be clear, >> You're proposing that an SP designate one or more of their domain names >>as SPIDs and these SPIDs would then be used in the E.164 Registry(ies)? >>=20 >> Since I was not one of those folks that want to do prefixing (one of >>the i3 drivers for numeric) I think I could live with this. It does meet >>the criteria of being available to all potential SPs, unlike, say, NECA >>stuff. >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, October 20, 2014 12:36 PM >> To: Richard Shockey >> Cc: Douglas Ranalli; Henning Schulzrinne; Gorman, Pierce A [NTK]; >>modern@ietf.org; PFAUTZ, PENN L >> Subject: Re: [Modern] Services >>=20 >>> Security .. Topology hiding.. This is not the DNS as you point out. >>>There >>> are lots of other reasons for this. But I=B1m pretty sure a name space >>>could >>> be created at minimal industry cost. >>>=20 >>=20 >> Possibly you are mistaking what I'm suggesting. >>=20 >> I'm suggesting that rather than creating a new identifier, let's say it >>was numeric, administered by someone, that we use a string that just >>happens to be the same as a domain owned by the SP, administered by the >>existing DNS registrars. >>=20 >> I'm not suggesting that there is anything in the DNS entry for that >>domain that we're using for identification. I'm just suggesting that >>the string "att.net" is a very fine SPID. AT&T already owns it. We >>have an acceptable administrator for it. It's globally unique. >>"broadband.com" is perfectly fine. "brianrosen.net" is also okay. It's >>a globally unique string, owned by the "Service Provider", capable of >>being used whenever a lookup in a database that needs some column for >>"service provider id". >>=20 >> What else do we need? >>=20 >> Brian >>=20 >>=20 >>=20 > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Mon Oct 20 20:35:06 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33F21AD008 for ; Mon, 20 Oct 2014 20:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 FX5f2NeOnCwn for ; Mon, 20 Oct 2014 20:34:57 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 323551AD011 for ; Mon, 20 Oct 2014 20:34:56 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0Mg== Date: Tue, 21 Oct 2014 03:34:54 +0000 References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,<99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> , <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> In-Reply-To: <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/4KFuv-DiRWCiNfOZYBabjeHMmT0 Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 03:35:00 -0000 I suspect we're trying to get at how many levels of indirection we allow be= fore we arrive at RFC 3263 and where, in one or more places, choices of ser= vice are expressed.=0A= =0A= Whether you designate a SPID or a domain name, there then has to be a secon= d step to get something resolvable. Needless to say, you could use both, si= nce a SPID would presumably translate mechanically into a domain name like = 1234.neca.org=0A= =0A= Also, I'm confused by the model that people have in mind - we seem to simul= taneously be talking about information that is being returned by a public n= umber directory (before you know who is "in charge" of the number) and high= ly-customized information that differs based on who's asking.=0A= =0A= We need both, and they may well use the same wire protocol, but, if we have= some kind of public numbering database, it can't tailor its response to th= e querier, by definition.=0A= =0A= To make this a bit more concrete:=0A= =0A= (1) Query a public numbering database with the MODERN protocol, with input = "number, service". Get a SPID or domain name, say modern.att.net.=0A= =0A= (2) Query domain name modern.att.net with MODERN, but with authentication. = Return customized SIP URL(s). [If the querier has no relationship to modern= .att.net, it would presumably get a generic answer for carriers without spe= cial arrangement or some version of "go away".]=0A= =0A= (3) Use RFC 3263 process for those URLs.=0A= =0A= Is that what people have in mind?=0A= =0A= ________________________________________=0A= From: Brian Rosen [br@brianrosen.net]=0A= Sent: Monday, October 20, 2014 10:11 AM=0A= To: Henning Schulzrinne=0A= Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g=0A= Subject: Re: [Modern] Services=0A= =0A= Okay, perhaps we are.=0A= =0A= I think =93media=94 is not a good service, but we=92ll see. I think it=92s= more like voice/video/text/event. They can always all have the same respo= nse.=0A= I think that using SRV is not a good enough routing protocol, although allo= wing it would be fine with me. SRV, like lots of things, does not properly= consider the source, nor the location, both requirements.=0A= =0A= It might be okay to have a two step route where the first step resolves to = a rendezvous for negotiation of the signaling and media interchange points,= but I would think that would be the result of the first =93modern=94 query= =3D it returns a URI where you negotiate interchange. The second step wou= ld have some notion of location and source identity and returns route.=0A= =0A= Brian=0A= =0A= =0A= > On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne wrote:=0A= >=0A= > I suspect we're talking past each other. I'm not advocating a "golden roo= t" or anything that looks like ENUM number-based mapping. As a strawman, co= nsider a JSON response within the MODERN context to a query for a phone num= ber, returning for you=0A= >=0A= > "media": "myphone.brianrosen.net"=0A= >=0A= > with myphone.brianrosen.net=0A= >=0A= > resolving to=0A= >=0A= > _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.=0A= >=0A= >=0A= > I assume we don't want to put IP addresses directly into the response, so= DNS enters the picture at some point.=0A= >=0A= > The alternative is to use the SRV or NAPTR service field (here, _sip._tcp= ) directly in the MODERN response. I can see advantages to both.=0A= >=0A= > Henning=0A= >=0A= > ________________________________________=0A= > From: Brian Rosen [br@brianrosen.net]=0A= > Sent: Monday, October 20, 2014 9:51 AM=0A= > To: Henning Schulzrinne=0A= > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.= org=0A= > Subject: Re: [Modern] Services=0A= >=0A= > I really would like to get away from DNS entirely. We can reuse concepts= , but I think DNS is not the appropriate way to get anything to do with E.1= 64s.=0A= > ENUM was a mistake, and one of the mistakes was using DNS. It=92s not th= e appropriate query mechanism, and it has a golden root problem. I remembe= r well the DNS guys questioning whether DNS was the right protocol when we = started ENUM. We were so sure it was. It was a mistake then, and it is no= w.=0A= >=0A= > Let=92s learn from that and stay away from DNS.=0A= >=0A= > We need a query with TN and service that returns either some form of serv= ice provider id/service URL and/or some form of route. I personally think = that it would be best to keep route separate from service provider id/URL b= ecause I do think the user controls that part of the record while the SP co= ntrols the route.=0A= >=0A= > Brian=0A= =0A= From nobody Tue Oct 21 03:42:31 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C88B1A03F9 for ; Tue, 21 Oct 2014 03:42:29 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=ham 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 WkwNuBeN1xBM for ; Tue, 21 Oct 2014 03:42:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::767]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC7D1A03A6 for ; Tue, 21 Oct 2014 03:42:26 -0700 (PDT) Received: from BY2FFO11FD002.protection.gbl (10.1.14.34) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Tue, 21 Oct 2014 10:42:02 +0000 Received: from plsasdm2.corp.sprint.com (144.230.168.26) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Tue, 21 Oct 2014 10:42:02 +0000 Received: from pdaasen2.corp.sprint.com (pdaasen2.corp.sprint.com [144.226.111.130]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9LAg0Cw031124 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 05:42:00 -0500 Received: from PREWE13M07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by pdaasen2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9LAfxlG010612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2014 05:41:59 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 06:41:58 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 05:41:57 -0500 From: "Gorman, Pierce A [NTK]" To: Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAAekCa Date: Tue, 21 Oct 2014 10:41:57 +0000 Message-ID: <145B0D1C-47CF-4F91-8DD0-4009770497AA@sprint.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,<99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> , <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.230.168.26; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(377454003)(51444003)(51704005)(189002)(199003)(110136001)(82746002)(23746002)(107046002)(26826002)(83716003)(2656002)(77096002)(84676001)(106116001)(92726001)(106466001)(92566001)(85852003)(95666004)(76176999)(50986999)(31966008)(54356999)(68736004)(19580405001)(44976005)(4396001)(99396003)(97736003)(21056001)(85306004)(6806004)(93886004)(50466002)(46102003)(86362001)(33656002)(80022003)(87936001)(36756003)(19580395003)(20776003)(120916001)(76482002)(47776003)(64706001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB038; H:plsasdm2.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB038; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0371762FE7 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.26 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.26; helo=plsasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.26) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/qiGmEdMT5LJFgCxd5Exxt2fL_FM Cc: Richard Shockey , "modern@ietf.org" , "PFAUTZ, PENN L" , Brian Rosen Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 10:42:29 -0000 Yes, but in step 2 replace "authentication" with "source_information". Cre= dentials are one form of source data. There could/will be others such as "= location". Pierce Sent from my iPad > On Oct 20, 2014, at 10:35 PM, "Henning Schulzrinne" wrote: > > I suspect we're trying to get at how many levels of indirection we allow = before we arrive at RFC 3263 and where, in one or more places, choices of s= ervice are expressed. > > Whether you designate a SPID or a domain name, there then has to be a sec= ond step to get something resolvable. Needless to say, you could use both, = since a SPID would presumably translate mechanically into a domain name lik= e 1234.neca.org > > Also, I'm confused by the model that people have in mind - we seem to sim= ultaneously be talking about information that is being returned by a public= number directory (before you know who is "in charge" of the number) and hi= ghly-customized information that differs based on who's asking. > > We need both, and they may well use the same wire protocol, but, if we ha= ve some kind of public numbering database, it can't tailor its response to = the querier, by definition. > > To make this a bit more concrete: > > (1) Query a public numbering database with the MODERN protocol, with inpu= t "number, service". Get a SPID or domain name, say modern.att.net. > > (2) Query domain name modern.att.net with MODERN, but with authentication= . Return customized SIP URL(s). [If the querier has no relationship to mode= rn.att.net, it would presumably get a generic answer for carriers without s= pecial arrangement or some version of "go away".] > > (3) Use RFC 3263 process for those URLs. > > Is that what people have in mind? > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 10:11 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.= org > Subject: Re: [Modern] Services > > Okay, perhaps we are. > > I think =93media=94 is not a good service, but we=92ll see. I think it= =92s more like voice/video/text/event. They can always all have the same r= esponse. > I think that using SRV is not a good enough routing protocol, although al= lowing it would be fine with me. SRV, like lots of things, does not proper= ly consider the source, nor the location, both requirements. > > It might be okay to have a two step route where the first step resolves t= o a rendezvous for negotiation of the signaling and media interchange point= s, but I would think that would be the result of the first =93modern=94 que= ry =3D it returns a URI where you negotiate interchange. The second step w= ould have some notion of location and source identity and returns route. > > Brian > > >> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne wrote: >> >> I suspect we're talking past each other. I'm not advocating a "golden ro= ot" or anything that looks like ENUM number-based mapping. As a strawman, c= onsider a JSON response within the MODERN context to a query for a phone nu= mber, returning for you >> >> "media": "myphone.brianrosen.net" >> >> with myphone.brianrosen.net >> >> resolving to >> >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >> >> >> I assume we don't want to put IP addresses directly into the response, s= o DNS enters the picture at some point. >> >> The alternative is to use the SRV or NAPTR service field (here, _sip._tc= p) directly in the MODERN response. I can see advantages to both. >> >> Henning >> >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf= .org >> Subject: Re: [Modern] Services >> >> I really would like to get away from DNS entirely. We can reuse concept= s, but I think DNS is not the appropriate way to get anything to do with E.= 164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It=92s not t= he appropriate query mechanism, and it has a golden root problem. I rememb= er well the DNS guys questioning whether DNS was the right protocol when we= started ENUM. We were so sure it was. It was a mistake then, and it is n= ow. >> >> Let=92s learn from that and stay away from DNS. >> >> We need a query with TN and service that returns either some form of ser= vice provider id/service URL and/or some form of route. I personally think= that it would be best to keep route separate from service provider id/URL = because I do think the user controls that part of the record while the SP c= ontrols the route. >> >> Brian > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Tue Oct 21 05:22:23 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB71A1B39 for ; Tue, 21 Oct 2014 05:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 qB4AS5x3gUBZ for ; Tue, 21 Oct 2014 05:22:14 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DA51A1B30 for ; Tue, 21 Oct 2014 05:22:14 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 6ff46445.2ae4b3284940.3671293.00-2426.10332058.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 21 Oct 2014 12:22:14 +0000 (UTC) X-MXL-Hash: 54464ff63c502a70-9786cf686f4a35034c16ff2cf085a39272e5cdb3 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 2ff46445.0.3671276.00-2364.10332007.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 21 Oct 2014 12:22:13 +0000 (UTC) X-MXL-Hash: 54464ff523c1cd00-bd9f11fe7c123da52af46f6ea1aa8a748911c5c4 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 s9LCM9lF007129; Tue, 21 Oct 2014 08:22:10 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9LCLo4C006854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Oct 2014 08:21:56 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 21 Oct 2014 12:21:29 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 08:21:29 -0400 From: "PFAUTZ, PENN L" To: Henning Schulzrinne , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAAllJw Date: Tue, 21 Oct 2014 12:21:29 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D6057421D4@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,<99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> , <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] 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-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=uw9Sko2_AAAA:8 a=HZJGGiqLAAAA:8 a=HLLxP2VMAAAA:8 a] X-AnalysisOut: [=A1X0JdhQAAAA:8 a=JUOOXLxzxKye14piXJIA:9 a=CjuIK1q_8ugA:10] X-AnalysisOut: [ a=lZB815dzVvQA:10 a=-zy3ex45pM4A:10 a=IY2HaCeeZdrcERPc:21] X-AnalysisOut: [ a=FzXLvfeRZ6Xxx7kQ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/hla7IJiSHj_pgBxISeZap294P1g Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 12:22:17 -0000 This is generally consistent with what I had in mind. -----Original Message----- From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Monday, October 20, 2014 11:35 PM To: Brian Rosen Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g Subject: RE: [Modern] Services I suspect we're trying to get at how many levels of indirection we allow be= fore we arrive at RFC 3263 and where, in one or more places, choices of ser= vice are expressed. Whether you designate a SPID or a domain name, there then has to be a secon= d step to get something resolvable. Needless to say, you could use both, si= nce a SPID would presumably translate mechanically into a domain name like = 1234.neca.org Also, I'm confused by the model that people have in mind - we seem to simul= taneously be talking about information that is being returned by a public n= umber directory (before you know who is "in charge" of the number) and high= ly-customized information that differs based on who's asking. We need both, and they may well use the same wire protocol, but, if we have= some kind of public numbering database, it can't tailor its response to th= e querier, by definition. To make this a bit more concrete: (1) Query a public numbering database with the MODERN protocol, with input = "number, service". Get a SPID or domain name, say modern.att.net. (2) Query domain name modern.att.net with MODERN, but with authentication. = Return customized SIP URL(s). [If the querier has no relationship to modern= .att.net, it would presumably get a generic answer for carriers without spe= cial arrangement or some version of "go away".] (3) Use RFC 3263 process for those URLs. Is that what people have in mind? ________________________________________ From: Brian Rosen [br@brianrosen.net] Sent: Monday, October 20, 2014 10:11 AM To: Henning Schulzrinne Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g Subject: Re: [Modern] Services Okay, perhaps we are. I think "media" is not a good service, but we'll see. I think it's more li= ke voice/video/text/event. They can always all have the same response. I think that using SRV is not a good enough routing protocol, although allo= wing it would be fine with me. SRV, like lots of things, does not properly= consider the source, nor the location, both requirements. It might be okay to have a two step route where the first step resolves to = a rendezvous for negotiation of the signaling and media interchange points,= but I would think that would be the result of the first "modern" query =3D= it returns a URI where you negotiate interchange. The second step would h= ave some notion of location and source identity and returns route. Brian > On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne wrote: > > I suspect we're talking past each other. I'm not advocating a "golden roo= t" or anything that looks like ENUM number-based mapping. As a strawman, co= nsider a JSON response within the MODERN context to a query for a phone num= ber, returning for you > > "media": "myphone.brianrosen.net" > > with myphone.brianrosen.net > > resolving to > > _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. > > > I assume we don't want to put IP addresses directly into the response, so= DNS enters the picture at some point. > > The alternative is to use the SRV or NAPTR service field (here, _sip._tcp= ) directly in the MODERN response. I can see advantages to both. > > Henning > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 9:51 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.= org > Subject: Re: [Modern] Services > > I really would like to get away from DNS entirely. We can reuse concepts= , but I think DNS is not the appropriate way to get anything to do with E.1= 64s. > ENUM was a mistake, and one of the mistakes was using DNS. It's not the = appropriate query mechanism, and it has a golden root problem. I remember = well the DNS guys questioning whether DNS was the right protocol when we st= arted ENUM. We were so sure it was. It was a mistake then, and it is now. > > Let's learn from that and stay away from DNS. > > We need a query with TN and service that returns either some form of serv= ice provider id/service URL and/or some form of route. I personally think = that it would be best to keep route separate from service provider id/URL b= ecause I do think the user controls that part of the record while the SP co= ntrols the route. > > Brian From nobody Tue Oct 21 06:13:50 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0B21A1B69 for ; Tue, 21 Oct 2014 06:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URI_TRY_3LD=0.001] autolearn=ham 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 nag-nAbpYMBa for ; Tue, 21 Oct 2014 06:13:35 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273CA1A1B5F for ; Tue, 21 Oct 2014 06:13:35 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id a108so805797qge.28 for ; Tue, 21 Oct 2014 06:13:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iZgSSv0Bg4MelL4ryI5PH7tYwIa3cKOpApCL56pk3jA=; b=M4zY06YuH1xpNkZ0Bazc7gZK6lzoLRFcTIFIX0r6kUNGCiQaTmCKFgHy+pVJjdyTPH gN0F/OPC0gXhWYdoWhoCuPpvtOekXq/EH22oxenr02HzeTgsaln864AtXKOjul8it6sv qkxaE6X6B74G4yqUYAKzWCt+uq80kE9QgomMsZHoZnEAf0HhKlHFy/FcTp9WR6chMBA5 QPTbz2KtlqKbG/b+G1qFK+hOGRheHJKhva3wKwGw6nnRmwcuc6a4xMqiq4oaSv6QAyKJ pQ+a/X56URpWkBgCRP+k3i8flo7La2xBgd1bidGdO0TksqSK+EGyBM282DP34aGYKeKE +U/g== X-Gm-Message-State: ALoCoQn+cea050jZS24cWGi1BTW1fxd2cquPllHvHmEbevjj/v9XlM3uzCfU353iZ0kqRFQVeljL X-Received: by 10.140.109.53 with SMTP id k50mr43575239qgf.83.1413897214300; Tue, 21 Oct 2014 06:13:34 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id v10sm10664239qar.10.2014.10.21.06.13.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 06:13:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: Date: Tue, 21 Oct 2014 09:13:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <, <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> <, <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> <>> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/U-D0vqt2VsRxhThQi2uMeJQU9Rc Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , "PFAUTZ, PENN L" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:13:44 -0000 It used to be that we did not want a public database of which service = provider(s) served a specific telephone number. Is that now not an = issue? Brian > On Oct 20, 2014, at 11:34 PM, Henning Schulzrinne = wrote: >=20 > I suspect we're trying to get at how many levels of indirection we = allow before we arrive at RFC 3263 and where, in one or more places, = choices of service are expressed. >=20 > Whether you designate a SPID or a domain name, there then has to be a = second step to get something resolvable. Needless to say, you could use = both, since a SPID would presumably translate mechanically into a domain = name like 1234.neca.org >=20 > Also, I'm confused by the model that people have in mind - we seem to = simultaneously be talking about information that is being returned by a = public number directory (before you know who is "in charge" of the = number) and highly-customized information that differs based on who's = asking. >=20 > We need both, and they may well use the same wire protocol, but, if we = have some kind of public numbering database, it can't tailor its = response to the querier, by definition. >=20 > To make this a bit more concrete: >=20 > (1) Query a public numbering database with the MODERN protocol, with = input "number, service". Get a SPID or domain name, say modern.att.net. >=20 > (2) Query domain name modern.att.net with MODERN, but with = authentication. Return customized SIP URL(s). [If the querier has no = relationship to modern.att.net, it would presumably get a generic answer = for carriers without special arrangement or some version of "go away".] >=20 > (3) Use RFC 3263 process for those URLs. >=20 > Is that what people have in mind? >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 10:11 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = modern@ietf.org > Subject: Re: [Modern] Services >=20 > Okay, perhaps we are. >=20 > I think =93media=94 is not a good service, but we=92ll see. I think = it=92s more like voice/video/text/event. They can always all have the = same response. > I think that using SRV is not a good enough routing protocol, although = allowing it would be fine with me. SRV, like lots of things, does not = properly consider the source, nor the location, both requirements. >=20 > It might be okay to have a two step route where the first step = resolves to a rendezvous for negotiation of the signaling and media = interchange points, but I would think that would be the result of the = first =93modern=94 query =3D it returns a URI where you negotiate = interchange. The second step would have some notion of location and = source identity and returns route. >=20 > Brian >=20 >=20 >> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne = wrote: >>=20 >> I suspect we're talking past each other. I'm not advocating a "golden = root" or anything that looks like ENUM number-based mapping. As a = strawman, consider a JSON response within the MODERN context to a query = for a phone number, returning for you >>=20 >> "media": "myphone.brianrosen.net" >>=20 >> with myphone.brianrosen.net >>=20 >> resolving to >>=20 >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>=20 >>=20 >> I assume we don't want to put IP addresses directly into the = response, so DNS enters the picture at some point. >>=20 >> The alternative is to use the SRV or NAPTR service field (here, = _sip._tcp) directly in the MODERN response. I can see advantages to = both. >>=20 >> Henning >>=20 >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; = modern@ietf.org >> Subject: Re: [Modern] Services >>=20 >> I really would like to get away from DNS entirely. We can reuse = concepts, but I think DNS is not the appropriate way to get anything to = do with E.164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It=92s = not the appropriate query mechanism, and it has a golden root problem. = I remember well the DNS guys questioning whether DNS was the right = protocol when we started ENUM. We were so sure it was. It was a = mistake then, and it is now. >>=20 >> Let=92s learn from that and stay away from DNS. >>=20 >> We need a query with TN and service that returns either some form of = service provider id/service URL and/or some form of route. I personally = think that it would be best to keep route separate from service provider = id/URL because I do think the user controls that part of the record = while the SP controls the route. >>=20 >> Brian >=20 From nobody Tue Oct 21 06:16:52 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8901A1B85 for ; Tue, 21 Oct 2014 06:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 iNmXKi_WwX5m for ; Tue, 21 Oct 2014 06:16:46 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139901A1B7F for ; Tue, 21 Oct 2014 06:16:46 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id ebc56445.2b7ae403f940.1264956.00-2497.3516624.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 21 Oct 2014 13:16:46 +0000 (UTC) X-MXL-Hash: 54465cbe4772bd7d-d89ccee25f3870285ed147a25a4d50f693166be2 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id bbc56445.0.1264942.00-2268.3516554.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 21 Oct 2014 13:16:44 +0000 (UTC) X-MXL-Hash: 54465cbc0eb3dbb3-0167a6a13441fd82ff35e2b23bcffbeb23caf29a 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 s9LDGgp9010965; Tue, 21 Oct 2014 09:16:43 -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 s9LDGIms010457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Oct 2014 09:16:26 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 21 Oct 2014 13:16:05 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 09:16:04 -0400 From: "PFAUTZ, PENN L" To: Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA56YA//+9qJA= Date: Tue, 21 Oct 2014 13:16:04 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605742230@MISOUT7MSGUSRDD.ITServices.sbc.com> References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,<99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> <,<818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> <>> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] 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-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=HLLxP2VMA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=uw9Sko2_AAAA:8 a=HZJGGiqLAAAA:8 a] X-AnalysisOut: [=A1X0JdhQAAAA:8 a=mEdCEiEeUVcoTV5Lj08A:9 a=CjuIK1q_8ugA:10] X-AnalysisOut: [ a=-zy3ex45pM4A:10 a=lZB815dzVvQA:10 a=kaSzFp3jFApUYmWU:21] X-AnalysisOut: [ a=DKgX2hZOkWPXca-t:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/g3HtTJOhWPorAIaP5-1IRvTJxjk Cc: "Gorman, Pierce A \[NTK\]" , "modern@ietf.org" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:16:48 -0000 I caught that too. How public would public be? I can imagine arguments for = some level of access control even if the database were on the Internet. And= I would want some protection from DDOS. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, October 21, 2014 9:14 AM To: Henning Schulzrinne Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g Subject: Re: [Modern] Services It used to be that we did not want a public database of which service provi= der(s) served a specific telephone number. Is that now not an issue? Brian > On Oct 20, 2014, at 11:34 PM, Henning Schulzrinne wrote: >=20 > I suspect we're trying to get at how many levels of indirection we allow = before we arrive at RFC 3263 and where, in one or more places, choices of s= ervice are expressed. >=20 > Whether you designate a SPID or a domain name, there then has to be a sec= ond step to get something resolvable. Needless to say, you could use both, = since a SPID would presumably translate mechanically into a domain name lik= e 1234.neca.org >=20 > Also, I'm confused by the model that people have in mind - we seem to sim= ultaneously be talking about information that is being returned by a public= number directory (before you know who is "in charge" of the number) and hi= ghly-customized information that differs based on who's asking. >=20 > We need both, and they may well use the same wire protocol, but, if we ha= ve some kind of public numbering database, it can't tailor its response to = the querier, by definition. >=20 > To make this a bit more concrete: >=20 > (1) Query a public numbering database with the MODERN protocol, with inpu= t "number, service". Get a SPID or domain name, say modern.att.net. >=20 > (2) Query domain name modern.att.net with MODERN, but with authentication= . Return customized SIP URL(s). [If the querier has no relationship to mode= rn.att.net, it would presumably get a generic answer for carriers without s= pecial arrangement or some version of "go away".] >=20 > (3) Use RFC 3263 process for those URLs. >=20 > Is that what people have in mind? >=20 > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 10:11 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.= org > Subject: Re: [Modern] Services >=20 > Okay, perhaps we are. >=20 > I think "media" is not a good service, but we'll see. I think it's more = like voice/video/text/event. They can always all have the same response. > I think that using SRV is not a good enough routing protocol, although al= lowing it would be fine with me. SRV, like lots of things, does not proper= ly consider the source, nor the location, both requirements. >=20 > It might be okay to have a two step route where the first step resolves t= o a rendezvous for negotiation of the signaling and media interchange point= s, but I would think that would be the result of the first "modern" query = =3D it returns a URI where you negotiate interchange. The second step woul= d have some notion of location and source identity and returns route. >=20 > Brian >=20 >=20 >> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne wrote: >>=20 >> I suspect we're talking past each other. I'm not advocating a "golden ro= ot" or anything that looks like ENUM number-based mapping. As a strawman, c= onsider a JSON response within the MODERN context to a query for a phone nu= mber, returning for you >>=20 >> "media": "myphone.brianrosen.net" >>=20 >> with myphone.brianrosen.net >>=20 >> resolving to >>=20 >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>=20 >>=20 >> I assume we don't want to put IP addresses directly into the response, s= o DNS enters the picture at some point. >>=20 >> The alternative is to use the SRV or NAPTR service field (here, _sip._tc= p) directly in the MODERN response. I can see advantages to both. >>=20 >> Henning >>=20 >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf= .org >> Subject: Re: [Modern] Services >>=20 >> I really would like to get away from DNS entirely. We can reuse concept= s, but I think DNS is not the appropriate way to get anything to do with E.= 164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It's not the= appropriate query mechanism, and it has a golden root problem. I remember= well the DNS guys questioning whether DNS was the right protocol when we s= tarted ENUM. We were so sure it was. It was a mistake then, and it is now= . >>=20 >> Let's learn from that and stay away from DNS. >>=20 >> We need a query with TN and service that returns either some form of ser= vice provider id/service URL and/or some form of route. I personally think= that it would be best to keep route separate from service provider id/URL = because I do think the user controls that part of the record while the SP c= ontrols the route. >>=20 >> Brian >=20 From nobody Tue Oct 21 07:13:53 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA0C1A1B80 for ; Tue, 21 Oct 2014 07:13:50 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=ham 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 opSb6RTQNmwR for ; Tue, 21 Oct 2014 07:13:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846781A1BA3 for ; Tue, 21 Oct 2014 07:13:44 -0700 (PDT) Received: from BN1AFFO11FD050.protection.gbl (10.58.52.32) by BN1AFFO11HUB029.protection.gbl (10.58.52.139) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Tue, 21 Oct 2014 14:13:38 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BN1AFFO11FD050.mail.protection.outlook.com (10.58.53.65) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Tue, 21 Oct 2014 14:13:38 +0000 Received: from pdaasen1.corp.sprint.com (mailhost.it.sprintspectrum.com [144.226.111.128]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9LEDat8013807 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 09:13:36 -0500 Received: from PLSWE13M07.ad.sprint.com (plswe13m07.corp.sprint.com [144.229.214.26]) by pdaasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9LEDZbm003458 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2014 09:13:35 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 09:13:33 -0500 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 09:13:33 -0500 From: "Gorman, Pierce A [NTK]" To: "PFAUTZ, PENN L" , Brian Rosen , Henning Schulzrinne Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA+GkAgAAAuAD//7tPwA== Date: Tue, 21 Oct 2014 14:13:32 +0000 Message-ID: References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,<99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> <,<818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> <>> <38726EDA2109264987B45E29E758C4D605742230@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D605742230@MISOUT7MSGUSRDD.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(377454003)(189002)(13464003)(24454002)(51444003)(199003)(92566001)(85852003)(120916001)(50466002)(97756001)(23726002)(54356999)(76176999)(86362001)(50986999)(108616004)(85306004)(46406003)(76482002)(99396003)(33646002)(46102003)(80022003)(93886004)(19580405001)(106466001)(77096002)(19580395003)(95666004)(31966008)(107046002)(26826002)(21056001)(64706001)(47776003)(87936001)(44976005)(106116001)(2656002)(6806004)(20776003)(4396001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB029; H:pdaasdm2.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpda2.sprint.com; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB029; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0371762FE7 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/hYCPwhmwfh2SDa1leJH2InuKPqs Cc: "modern@ietf.org" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:13:50 -0000 I am very leary of a public database. SPAM over Internet Telephony (SPIT) = is just as much a concern as it ever was. If the database is to be used by "carriers" of telecommunications services = (e.g., voice, 2-way video, presence capabilities, geo-location, emergency s= ervices call/text/etc), I would want the same restrictions to access as are= enjoyed by LERG and NPAC. I understand OTT providers may require access a= s well (I assume they will) but I would definitely not want it to be as ope= n as DNS. Best regards, Pierce Gorman Voice Architecture Core Planning/Sprint 913-439-4368 (Desk) -----Original Message----- From: PFAUTZ, PENN L [mailto:pp3129@att.com] Sent: October 21, 2014 8:16 AM To: Brian Rosen; Henning Schulzrinne Cc: Richard Shockey; Gorman, Pierce A [NTK]; modern@ietf.org Subject: RE: [Modern] Services I caught that too. How public would public be? I can imagine arguments for = some level of access control even if the database were on the Internet. And= I would want some protection from DDOS. -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, October 21, 2014 9:14 AM To: Henning Schulzrinne Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g Subject: Re: [Modern] Services It used to be that we did not want a public database of which service provi= der(s) served a specific telephone number. Is that now not an issue? Brian > On Oct 20, 2014, at 11:34 PM, Henning Schulzrinne wrote: > > I suspect we're trying to get at how many levels of indirection we allow = before we arrive at RFC 3263 and where, in one or more places, choices of s= ervice are expressed. > > Whether you designate a SPID or a domain name, there then has to be a sec= ond step to get something resolvable. Needless to say, you could use both, = since a SPID would presumably translate mechanically into a domain name lik= e 1234.neca.org > > Also, I'm confused by the model that people have in mind - we seem to sim= ultaneously be talking about information that is being returned by a public= number directory (before you know who is "in charge" of the number) and hi= ghly-customized information that differs based on who's asking. > > We need both, and they may well use the same wire protocol, but, if we ha= ve some kind of public numbering database, it can't tailor its response to = the querier, by definition. > > To make this a bit more concrete: > > (1) Query a public numbering database with the MODERN protocol, with inpu= t "number, service". Get a SPID or domain name, say modern.att.net. > > (2) Query domain name modern.att.net with MODERN, but with authentication= . Return customized SIP URL(s). [If the querier has no relationship to mode= rn.att.net, it would presumably get a generic answer for carriers without s= pecial arrangement or some version of "go away".] > > (3) Use RFC 3263 process for those URLs. > > Is that what people have in mind? > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Monday, October 20, 2014 10:11 AM > To: Henning Schulzrinne > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.= org > Subject: Re: [Modern] Services > > Okay, perhaps we are. > > I think "media" is not a good service, but we'll see. I think it's more = like voice/video/text/event. They can always all have the same response. > I think that using SRV is not a good enough routing protocol, although al= lowing it would be fine with me. SRV, like lots of things, does not proper= ly consider the source, nor the location, both requirements. > > It might be okay to have a two step route where the first step resolves t= o a rendezvous for negotiation of the signaling and media interchange point= s, but I would think that would be the result of the first "modern" query = =3D it returns a URI where you negotiate interchange. The second step woul= d have some notion of location and source identity and returns route. > > Brian > > >> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne wrote: >> >> I suspect we're talking past each other. I'm not advocating a "golden ro= ot" or anything that looks like ENUM number-based mapping. As a strawman, c= onsider a JSON response within the MODERN context to a query for a phone nu= mber, returning for you >> >> "media": "myphone.brianrosen.net" >> >> with myphone.brianrosen.net >> >> resolving to >> >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >> >> >> I assume we don't want to put IP addresses directly into the response, s= o DNS enters the picture at some point. >> >> The alternative is to use the SRV or NAPTR service field (here, _sip._tc= p) directly in the MODERN response. I can see advantages to both. >> >> Henning >> >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf= .org >> Subject: Re: [Modern] Services >> >> I really would like to get away from DNS entirely. We can reuse concept= s, but I think DNS is not the appropriate way to get anything to do with E.= 164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It's not the= appropriate query mechanism, and it has a golden root problem. I remember= well the DNS guys questioning whether DNS was the right protocol when we s= tarted ENUM. We were so sure it was. It was a mistake then, and it is now= . >> >> Let's learn from that and stay away from DNS. >> >> We need a query with TN and service that returns either some form of ser= vice provider id/service URL and/or some form of route. I personally think= that it would be best to keep route separate from service provider id/URL = because I do think the user controls that part of the record while the SP c= ontrols the route. >> >> Brian > ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Tue Oct 21 10:42:09 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370F1A1C05 for ; Tue, 21 Oct 2014 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=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 xL4ogbs4JSBv for ; Tue, 21 Oct 2014 10:42:06 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 5FECE1A1BC9 for ; Tue, 21 Oct 2014 10:42:06 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s9LHg6Pb016619 for ; Tue, 21 Oct 2014 13:42:06 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1q5qdkgty6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Oct 2014 13:42:05 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 21 Oct 2014 13:42:04 -0400 From: "McGarry, Tom" To: "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wA Date: Tue, 21 Oct 2014 17:42:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.204.176] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8DBA310AC7DCBF4087CDE104D25FD514@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7597 signatures=670556 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410210176 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/_7UBiv4Je3zzkcnfqV8rYnv6flk Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:42:08 -0000 So there seems to be some pushback on a "public DB" and I tend to agree. This is why I've advocated that the administrator distributes these DBs to others, e.g., ISPs. Make them part of service providers' infrastructure with all the attendant security. The challenges here are around updating it and securing the data from the entity that is now hosting it. Securing primarily means making sure it can't be modified. But it could even mean protecting it from being mined. =20 On 10/20/14 11:34 PM, "Henning Schulzrinne" wrote: > >I suspect we're trying to get at how many levels of indirection we allow >before we arrive at RFC 3263 and where, in one or more places, choices of >service are expressed. > >Whether you designate a SPID or a domain name, there then has to be a >second step to get something resolvable. Needless to say, you could use >both, since a SPID would presumably translate mechanically into a domain >name like 1234.neca.org > >Also, I'm confused by the model that people have in mind - we seem to >simultaneously be talking about information that is being returned by a >public number directory (before you know who is "in charge" of the >number) and highly-customized information that differs based on who's >asking. > >We need both, and they may well use the same wire protocol, but, if we >have some kind of public numbering database, it can't tailor its response >to the querier, by definition. > >To make this a bit more concrete: > >(1) Query a public numbering database with the MODERN protocol, with >input "number, service". Get a SPID or domain name, say modern.att.net. > >(2) Query domain name modern.att.net with MODERN, but with >authentication. Return customized SIP URL(s). [If the querier has no >relationship to modern.att.net, it would presumably get a generic answer >for carriers without special arrangement or some version of "go away".] > >(3) Use RFC 3263 process for those URLs. > >Is that what people have in mind? > >________________________________________ >From: Brian Rosen [br@brianrosen.net] >Sent: Monday, October 20, 2014 10:11 AM >To: Henning Schulzrinne >Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >modern@ietf.org >Subject: Re: [Modern] Services > >Okay, perhaps we are. > >I think =B3media=B2 is not a good service, but we=B9ll see. I think it=B9= s more >like voice/video/text/event. They can always all have the same response. >I think that using SRV is not a good enough routing protocol, although >allowing it would be fine with me. SRV, like lots of things, does not >properly consider the source, nor the location, both requirements. > >It might be okay to have a two step route where the first step resolves >to a rendezvous for negotiation of the signaling and media interchange >points, but I would think that would be the result of the first =B3modern= =B2 >query =3D it returns a URI where you negotiate interchange. The second >step would have some notion of location and source identity and returns >route. > >Brian > > >> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne >> wrote: >> >> I suspect we're talking past each other. I'm not advocating a "golden >>root" or anything that looks like ENUM number-based mapping. As a >>strawman, consider a JSON response within the MODERN context to a query >>for a phone number, returning for you >> >> "media": "myphone.brianrosen.net" >> >> with myphone.brianrosen.net >> >> resolving to >> >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >> >> >> I assume we don't want to put IP addresses directly into the response, >>so DNS enters the picture at some point. >> >> The alternative is to use the SRV or NAPTR service field (here, >>_sip._tcp) directly in the MODERN response. I can see advantages to both. >> >> Henning >> >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 9:51 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>modern@ietf.org >> Subject: Re: [Modern] Services >> >> I really would like to get away from DNS entirely. We can reuse >>concepts, but I think DNS is not the appropriate way to get anything to >>do with E.164s. >> ENUM was a mistake, and one of the mistakes was using DNS. It=B9s not >>the appropriate query mechanism, and it has a golden root problem. I >>remember well the DNS guys questioning whether DNS was the right >>protocol when we started ENUM. We were so sure it was. It was a >>mistake then, and it is now. >> >> Let=B9s learn from that and stay away from DNS. >> >> We need a query with TN and service that returns either some form of >>service provider id/service URL and/or some form of route. I personally >>think that it would be best to keep route separate from service provider >>id/URL because I do think the user controls that part of the record >>while the SP controls the route. >> >> Brian > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAAIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3Dp-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s=3D= 0X93 >agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e=3D=20 From nobody Tue Oct 21 11:02:36 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764D91A802E for ; Tue, 21 Oct 2014 11:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=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 mLtJ-J5aUqB8 for ; Tue, 21 Oct 2014 11:02:30 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 340E31A86F8 for ; Tue, 21 Oct 2014 11:02:30 -0700 (PDT) Received: (qmail 8774 invoked by uid 0); 21 Oct 2014 18:02:26 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy3.mail.unifiedlayer.com with SMTP; 21 Oct 2014 18:02:26 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 60251p00l1MNPNq01028dM; Tue, 21 Oct 2014 18:02:12 -0600 X-Authority-Analysis: v=2.1 cv=fdw+lSgF c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=zsg0ix40YlEA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=izV7ms69AAAA:8 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=uw9Sko2_AAAA:8 a=HZJGGiqLAAAA:8 a=A1X0JdhQAAAA:8 a=LOspff8x5xj9ZXKaVlwA:9 a=vyTlAAK3LY3e0UW-:21 a=wBwEGzrzyIzM5rY3:21 a=wPNLvfGTeEIA:10 a=DzjOOp_o1eYA:10 a=2aF6lfeD-CsA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA:10 a=-zy3ex45pM4A:10 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:CC:To:From:Subject:Date; bh=nkZl0FQJutqMGaoHk6qYkq0lmGeKYUJHvU4hpfA8Kxg=; b=eQkspsRya5dukVM/a2BP6VEMD5X0YhlBC16TGBSkiwVwHetqqugQ2wRcoKxJ/jtcuCgGTFqPO+8IoCnh51zoFDMLfNulfMAjeZoorLhQbXYbO7+DQVVtj0P09WG1Tv7u; Received: from [72.66.64.164] (port=50185 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Xgdkz-0006Qx-2g; Tue, 21 Oct 2014 12:02:06 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Tue, 21 Oct 2014 14:02:01 -0400 From: Richard Shockey To: "Gorman, Pierce A [NTK]" Message-ID: Thread-Topic: [Modern] Services References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> <38726EDA2109264987B45E29E758C4D605742230@MISOUT7MSGUSRDD.ITServices.sbc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/XIgGTnlELvUeR4H1_czI-vgWZwI Cc: "modern@ietf.org" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:02:35 -0000 +1 Also the regulators want some level of control here for perfectly senseable reasons. I=B9ve certainly argued that access to the national numbering plan and its databases should imply a set of obligations. By definition it is a public resource. On 10/21/14, 10:13 AM, "Gorman, Pierce A [NTK]" wrote: >I am very leary of a public database. SPAM over Internet Telephony >(SPIT) is just as much a concern as it ever was. > >If the database is to be used by "carriers" of telecommunications >services (e.g., voice, 2-way video, presence capabilities, geo-location, >emergency services call/text/etc), I would want the same restrictions to >access as are enjoyed by LERG and NPAC. I understand OTT providers may >require access as well (I assume they will) but I would definitely not >want it to be as open as DNS. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > > >-----Original Message----- >From: PFAUTZ, PENN L [mailto:pp3129@att.com] >Sent: October 21, 2014 8:16 AM >To: Brian Rosen; Henning Schulzrinne >Cc: Richard Shockey; Gorman, Pierce A [NTK]; modern@ietf.org >Subject: RE: [Modern] Services > >I caught that too. How public would public be? I can imagine arguments >for some level of access control even if the database were on the >Internet. And I would want some protection from DDOS. > >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Tuesday, October 21, 2014 9:14 AM >To: Henning Schulzrinne >Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >modern@ietf.org >Subject: Re: [Modern] Services > >It used to be that we did not want a public database of which service >provider(s) served a specific telephone number. Is that now not an issue? > >Brian > >> On Oct 20, 2014, at 11:34 PM, Henning Schulzrinne >> wrote: >> >> I suspect we're trying to get at how many levels of indirection we >>allow before we arrive at RFC 3263 and where, in one or more places, >>choices of service are expressed. >> >> Whether you designate a SPID or a domain name, there then has to be a >>second step to get something resolvable. Needless to say, you could use >>both, since a SPID would presumably translate mechanically into a domain >>name like 1234.neca.org >> >> Also, I'm confused by the model that people have in mind - we seem to >>simultaneously be talking about information that is being returned by a >>public number directory (before you know who is "in charge" of the >>number) and highly-customized information that differs based on who's >>asking. >> >> We need both, and they may well use the same wire protocol, but, if we >>have some kind of public numbering database, it can't tailor its >>response to the querier, by definition. >> >> To make this a bit more concrete: >> >> (1) Query a public numbering database with the MODERN protocol, with >>input "number, service". Get a SPID or domain name, say modern.att.net. >> >> (2) Query domain name modern.att.net with MODERN, but with >>authentication. Return customized SIP URL(s). [If the querier has no >>relationship to modern.att.net, it would presumably get a generic answer >>for carriers without special arrangement or some version of "go away".] >> >> (3) Use RFC 3263 process for those URLs. >> >> Is that what people have in mind? >> >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 10:11 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>modern@ietf.org >> Subject: Re: [Modern] Services >> >> Okay, perhaps we are. >> >> I think "media" is not a good service, but we'll see. I think it's >>more like voice/video/text/event. They can always all have the same >>response. >> I think that using SRV is not a good enough routing protocol, although >>allowing it would be fine with me. SRV, like lots of things, does not >>properly consider the source, nor the location, both requirements. >> >> It might be okay to have a two step route where the first step resolves >>to a rendezvous for negotiation of the signaling and media interchange >>points, but I would think that would be the result of the first "modern" >>query =3D it returns a URI where you negotiate interchange. The second >>step would have some notion of location and source identity and returns >>route. >> >> Brian >> >> >>> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne >>> wrote: >>> >>> I suspect we're talking past each other. I'm not advocating a "golden >>>root" or anything that looks like ENUM number-based mapping. As a >>>strawman, consider a JSON response within the MODERN context to a query >>>for a phone number, returning for you >>> >>> "media": "myphone.brianrosen.net" >>> >>> with myphone.brianrosen.net >>> >>> resolving to >>> >>> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>> >>> >>> I assume we don't want to put IP addresses directly into the response, >>>so DNS enters the picture at some point. >>> >>> The alternative is to use the SRV or NAPTR service field (here, >>>_sip._tcp) directly in the MODERN response. I can see advantages to >>>both. >>> >>> Henning >>> >>> ________________________________________ >>> From: Brian Rosen [br@brianrosen.net] >>> Sent: Monday, October 20, 2014 9:51 AM >>> To: Henning Schulzrinne >>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>>modern@ietf.org >>> Subject: Re: [Modern] Services >>> >>> I really would like to get away from DNS entirely. We can reuse >>>concepts, but I think DNS is not the appropriate way to get anything to >>>do with E.164s. >>> ENUM was a mistake, and one of the mistakes was using DNS. It's not >>>the appropriate query mechanism, and it has a golden root problem. I >>>remember well the DNS guys questioning whether DNS was the right >>>protocol when we started ENUM. We were so sure it was. It was a >>>mistake then, and it is now. >>> >>> Let's learn from that and stay away from DNS. >>> >>> We need a query with TN and service that returns either some form of >>>service provider id/service URL and/or some form of route. I >>>personally think that it would be best to keep route separate from >>>service provider id/URL because I do think the user controls that part >>>of the record while the SP controls the route. >>> >>> Brian >> > > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. From nobody Tue Oct 21 11:10:48 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798A91A872C for ; Tue, 21 Oct 2014 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 QtKOiBw68pEo for ; Tue, 21 Oct 2014 11:10:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8DAC11A8732 for ; Tue, 21 Oct 2014 11:07:01 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s9LI70FV092395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 13:07:00 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5446A0C4.4000704@nostrum.com> Date: Tue, 21 Oct 2014 13:07:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "McGarry, Tom" , "modern@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/modern/Jg2nMM2y3iKiggYTwtjnTyYc-rg Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:10:33 -0000 Hrm. I've heard OTT providers tossed around in this discussion as a potential consumer of this data. It sounds like the last few messages have been angling towards solutions that would provide high barriers to entry to becoming such a provider. I'm thinking we should put some thought into how to deploy a system that doesn't exclude small new players, while honoring the valid operational concerns of incumbents. I'm very suspect of the naive approach of "well, let's just make it a secret database that requires a special handshake and/or the right amount of money to access." /a On 10/21/14 12:42, McGarry, Tom wrote: > So there seems to be some pushback on a "public DB" and I tend to agree. > This is why I've advocated that the administrator distributes these DBs to > others, e.g., ISPs. Make them part of service providers' infrastructure > with all the attendant security. The challenges here are around updating > it and securing the data from the entity that is now hosting it. Securing > primarily means making sure it can't be modified. But it could even mean > protecting it from being mined. > > > > On 10/20/14 11:34 PM, "Henning Schulzrinne" > wrote: > >> >> I suspect we're trying to get at how many levels of indirection we allow >> before we arrive at RFC 3263 and where, in one or more places, choices of >> service are expressed. >> >> Whether you designate a SPID or a domain name, there then has to be a >> second step to get something resolvable. Needless to say, you could use >> both, since a SPID would presumably translate mechanically into a domain >> name like 1234.neca.org >> >> Also, I'm confused by the model that people have in mind - we seem to >> simultaneously be talking about information that is being returned by a >> public number directory (before you know who is "in charge" of the >> number) and highly-customized information that differs based on who's >> asking. >> >> We need both, and they may well use the same wire protocol, but, if we >> have some kind of public numbering database, it can't tailor its response >> to the querier, by definition. >> >> To make this a bit more concrete: >> >> (1) Query a public numbering database with the MODERN protocol, with >> input "number, service". Get a SPID or domain name, say modern.att.net. >> >> (2) Query domain name modern.att.net with MODERN, but with >> authentication. Return customized SIP URL(s). [If the querier has no >> relationship to modern.att.net, it would presumably get a generic answer >> for carriers without special arrangement or some version of "go away".] >> >> (3) Use RFC 3263 process for those URLs. >> >> Is that what people have in mind? >> >> ________________________________________ >> From: Brian Rosen [br@brianrosen.net] >> Sent: Monday, October 20, 2014 10:11 AM >> To: Henning Schulzrinne >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >> modern@ietf.org >> Subject: Re: [Modern] Services >> >> Okay, perhaps we are. >> >> I think ³media² is not a good service, but we¹ll see. I think it¹s more >> like voice/video/text/event. They can always all have the same response. >> I think that using SRV is not a good enough routing protocol, although >> allowing it would be fine with me. SRV, like lots of things, does not >> properly consider the source, nor the location, both requirements. >> >> It might be okay to have a two step route where the first step resolves >> to a rendezvous for negotiation of the signaling and media interchange >> points, but I would think that would be the result of the first ³modern² >> query = it returns a URI where you negotiate interchange. The second >> step would have some notion of location and source identity and returns >> route. >> >> Brian >> >> >>> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne >>> wrote: >>> >>> I suspect we're talking past each other. I'm not advocating a "golden >>> root" or anything that looks like ENUM number-based mapping. As a >>> strawman, consider a JSON response within the MODERN context to a query >>> for a phone number, returning for you >>> >>> "media": "myphone.brianrosen.net" >>> >>> with myphone.brianrosen.net >>> >>> resolving to >>> >>> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>> >>> >>> I assume we don't want to put IP addresses directly into the response, >>> so DNS enters the picture at some point. >>> >>> The alternative is to use the SRV or NAPTR service field (here, >>> _sip._tcp) directly in the MODERN response. I can see advantages to both. >>> >>> Henning >>> >>> ________________________________________ >>> From: Brian Rosen [br@brianrosen.net] >>> Sent: Monday, October 20, 2014 9:51 AM >>> To: Henning Schulzrinne >>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>> modern@ietf.org >>> Subject: Re: [Modern] Services >>> >>> I really would like to get away from DNS entirely. We can reuse >>> concepts, but I think DNS is not the appropriate way to get anything to >>> do with E.164s. >>> ENUM was a mistake, and one of the mistakes was using DNS. It¹s not >>> the appropriate query mechanism, and it has a golden root problem. I >>> remember well the DNS guys questioning whether DNS was the right >>> protocol when we started ENUM. We were so sure it was. It was a >>> mistake then, and it is now. >>> >>> Let¹s learn from that and stay away from DNS. >>> >>> We need a query with TN and service that returns either some form of >>> service provider id/service URL and/or some form of route. I personally >>> think that it would be best to keep route separate from service provider >>> id/URL because I do think the user controls that part of the record >>> while the SP controls the route. >>> >>> Brian >> >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >> listinfo_modern&d=AAIF-g&c=MOptNlVtIETeDALC_lULrw&r=4Klm32iB7HufveeIDcLext >> Z1ooNcfp01IYIaVqsORjI&m=p-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s=0X93 >> agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e= > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Tue Oct 21 12:15:57 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FB31A049A for ; Tue, 21 Oct 2014 12:15:48 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=ham 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 Bol3R407b1vh for ; Tue, 21 Oct 2014 12:15:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34D81A03A5 for ; Tue, 21 Oct 2014 12:15:41 -0700 (PDT) Received: from BY2FFO11FD041.protection.gbl (10.1.14.30) by BY2FFO11HUB049.protection.gbl (10.1.14.88) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Tue, 21 Oct 2014 19:15:27 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BY2FFO11FD041.mail.protection.outlook.com (10.1.14.226) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Tue, 21 Oct 2014 19:15:27 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9LJFPqw029814 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2014 14:15:26 -0500 Received: from PREWE13M08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9LJFP3E020662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Oct 2014 14:15:25 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 21 Oct 2014 15:15:24 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0847.030; Tue, 21 Oct 2014 14:15:23 -0500 From: "Gorman, Pierce A [NTK]" To: Adam Roach , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABazgD//73MUA== Date: Tue, 21 Oct 2014 19:15:22 +0000 Message-ID: <9a0e4d630a154c0db8d4dad3039fd455@PLSWE13M08.ad.sprint.com> References: <5446A0C4.4000704@nostrum.com> In-Reply-To: <5446A0C4.4000704@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.123.104.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(24454002)(51444003)(199003)(51704005)(189002)(377454003)(479174003)(21056001)(26826002)(95666004)(31966008)(4396001)(44976005)(6806004)(107886001)(107046002)(106116001)(106466001)(19580405001)(77096002)(19580395003)(15975445006)(2656002)(87936001)(64706001)(20776003)(47776003)(23676002)(50986999)(76176999)(54356999)(575784001)(86362001)(92566001)(85852003)(108616004)(85306004)(46102003)(80022003)(2501002)(33646002)(50466002)(76482002)(99396003)(120916001)(24736002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB049; H:pdaasdm2.corp.sprint.com; FPR:; PTR:smtpda2.sprint.com; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB049; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0371762FE7 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Pierce.Gorman@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/rtTQ3B7mtJyz5eVbdn3NBnD6GlM Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:15:49 -0000 TEVSRyBhbmQgTlBBQyBtYXkgZmFsbCBpbnRvIHlvdXIgY2F0ZWdvcmllcyBvZiBuYcOvdmUsIHNl Y3JldCwgcmVxdWlyaW5nIGEgc3BlY2lhbCBoYW5kc2hha2UsIGFuZCByaWdodCBhbW91bnQgb2Yg bW9uZXkgdG8gYWNjZXNzLCBidXQgSSB3b3VsZCBhcmd1ZSB3aXRoIG5hw692ZS4gIDotKQ0KDQpZ b3VyIGNvbmNlcm4gaXMgc3RpbGwgdmFsaWQgYW5kIEkgYWdyZWUuICBTbGFtbWluZyBoYXMgYmVl biBhIHByb2JsZW0gaW4gdGhlIHBhc3QgZXZlbiB3aXRoIGNvbnRyb2xsZWQgYWNjZXNzLiAgUGVy aGFwcyBkYXRhYmFzZSBjb250ZW50IG9mIHNlcnZpY2VzL1NQIGFzc29jaWF0ZWQgd2l0aCBUTihz KSBhc3NvY2lhdGVkIHdpdGggYSB0eXBpY2FsIGNvbnN1bWVyIHN1YnNjcmliZXIgY2FuIGJlIGNv bnRyb2xsZWQgYnkgdGhlIHN1YnNjcmliZXIgdGhlbXNlbHZlcz8gIFRoZXkgZG8gc28gdGhyb3Vn aCB0aGUgcHJveHkgb2YgdGhlaXIgdGVsZXBob25lIHNlcnZpY2UgY2FycmllcihzKSB0b2RheSwg YnV0IE1PREVSTiB0ZWNobm9sb2d5IChwdW4gaW50ZW5kZWQpIG1pZ2h0IHN1cHBvcnQgYSBtb3Jl IGRpcmVjdCByb2xlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KUGllcmNlIEdvcm1hbg0KVm9pY2Ug QXJjaGl0ZWN0dXJlDQpDb3JlIFBsYW5uaW5nL1NwcmludA0KOTEzLTQzOS00MzY4IChEZXNrKQ0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rl cm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IE9jdG9i ZXIgMjEsIDIwMTQgMTowNyBQTQ0KVG86IE1jR2FycnksIFRvbTsgbW9kZXJuQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW01vZGVybl0gU2VydmljZXMNCg0KSHJtLiBJJ3ZlIGhlYXJkIE9UVCBwcm92 aWRlcnMgdG9zc2VkIGFyb3VuZCBpbiB0aGlzIGRpc2N1c3Npb24gYXMgYSBwb3RlbnRpYWwgY29u c3VtZXIgb2YgdGhpcyBkYXRhLiBJdCBzb3VuZHMgbGlrZSB0aGUgbGFzdCBmZXcgbWVzc2FnZXMg aGF2ZSBiZWVuIGFuZ2xpbmcgdG93YXJkcyBzb2x1dGlvbnMgdGhhdCB3b3VsZCBwcm92aWRlIGhp Z2ggYmFycmllcnMgdG8gZW50cnkgdG8gYmVjb21pbmcgc3VjaCBhIHByb3ZpZGVyLg0KDQpJJ20g dGhpbmtpbmcgd2Ugc2hvdWxkIHB1dCBzb21lIHRob3VnaHQgaW50byBob3cgdG8gZGVwbG95IGEg c3lzdGVtIHRoYXQgZG9lc24ndCBleGNsdWRlIHNtYWxsIG5ldyBwbGF5ZXJzLCB3aGlsZSBob25v cmluZyB0aGUgdmFsaWQgb3BlcmF0aW9uYWwgY29uY2VybnMgb2YgaW5jdW1iZW50cy4gSSdtIHZl cnkgc3VzcGVjdCBvZiB0aGUgbmFpdmUgYXBwcm9hY2ggb2YgIndlbGwsIGxldCdzIGp1c3QgbWFr ZSBpdCBhIHNlY3JldCBkYXRhYmFzZSB0aGF0IHJlcXVpcmVzIGEgc3BlY2lhbCBoYW5kc2hha2Ug YW5kL29yIHRoZSByaWdodCBhbW91bnQgb2YgbW9uZXkgdG8gYWNjZXNzLiINCg0KL2ENCg0KT24g MTAvMjEvMTQgMTI6NDIsIE1jR2FycnksIFRvbSB3cm90ZToNCj4gU28gdGhlcmUgc2VlbXMgdG8g YmUgc29tZSBwdXNoYmFjayBvbiBhICJwdWJsaWMgREIiIGFuZCBJIHRlbmQgdG8gYWdyZWUuDQo+ IFRoaXMgaXMgd2h5IEkndmUgYWR2b2NhdGVkIHRoYXQgdGhlIGFkbWluaXN0cmF0b3IgZGlzdHJp YnV0ZXMgdGhlc2UNCj4gREJzIHRvIG90aGVycywgZS5nLiwgSVNQcy4gIE1ha2UgdGhlbSBwYXJ0 IG9mIHNlcnZpY2UgcHJvdmlkZXJzJw0KPiBpbmZyYXN0cnVjdHVyZSB3aXRoIGFsbCB0aGUgYXR0 ZW5kYW50IHNlY3VyaXR5LiAgVGhlIGNoYWxsZW5nZXMgaGVyZQ0KPiBhcmUgYXJvdW5kIHVwZGF0 aW5nIGl0IGFuZCBzZWN1cmluZyB0aGUgZGF0YSBmcm9tIHRoZSBlbnRpdHkgdGhhdCBpcw0KPiBu b3cgaG9zdGluZyBpdC4gIFNlY3VyaW5nIHByaW1hcmlseSBtZWFucyBtYWtpbmcgc3VyZSBpdCBj YW4ndCBiZQ0KPiBtb2RpZmllZC4gIEJ1dCBpdCBjb3VsZCBldmVuIG1lYW4gcHJvdGVjdGluZyBp dCBmcm9tIGJlaW5nIG1pbmVkLg0KPg0KPg0KPg0KPiBPbiAxMC8yMC8xNCAxMTozNCBQTSwgIkhl bm5pbmcgU2NodWx6cmlubmUiDQo+IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+DQo+IHdy b3RlOg0KPg0KPj4gPGh0bWw+DQo+PiBJIHN1c3BlY3Qgd2UncmUgdHJ5aW5nIHRvIGdldCBhdCBo b3cgbWFueSBsZXZlbHMgb2YgaW5kaXJlY3Rpb24gd2UNCj4+IGFsbG93IGJlZm9yZSB3ZSBhcnJp dmUgYXQgUkZDIDMyNjMgYW5kIHdoZXJlLCBpbiBvbmUgb3IgbW9yZSBwbGFjZXMsDQo+PiBjaG9p Y2VzIG9mIHNlcnZpY2UgYXJlIGV4cHJlc3NlZC4NCj4+DQo+PiBXaGV0aGVyIHlvdSBkZXNpZ25h dGUgYSBTUElEIG9yIGEgZG9tYWluIG5hbWUsIHRoZXJlIHRoZW4gaGFzIHRvIGJlIGENCj4+IHNl Y29uZCBzdGVwIHRvIGdldCBzb21ldGhpbmcgcmVzb2x2YWJsZS4gTmVlZGxlc3MgdG8gc2F5LCB5 b3UgY291bGQNCj4+IHVzZSBib3RoLCBzaW5jZSBhIFNQSUQgd291bGQgcHJlc3VtYWJseSB0cmFu c2xhdGUgbWVjaGFuaWNhbGx5IGludG8gYQ0KPj4gZG9tYWluIG5hbWUgbGlrZSAxMjM0Lm5lY2Eu b3JnDQo+Pg0KPj4gQWxzbywgSSdtIGNvbmZ1c2VkIGJ5IHRoZSBtb2RlbCB0aGF0IHBlb3BsZSBo YXZlIGluIG1pbmQgLSB3ZSBzZWVtIHRvDQo+PiBzaW11bHRhbmVvdXNseSBiZSB0YWxraW5nIGFi b3V0IGluZm9ybWF0aW9uIHRoYXQgaXMgYmVpbmcgcmV0dXJuZWQgYnkNCj4+IGEgcHVibGljIG51 bWJlciBkaXJlY3RvcnkgKGJlZm9yZSB5b3Uga25vdyB3aG8gaXMgImluIGNoYXJnZSIgb2YgdGhl DQo+PiBudW1iZXIpIGFuZCBoaWdobHktY3VzdG9taXplZCBpbmZvcm1hdGlvbiB0aGF0IGRpZmZl cnMgYmFzZWQgb24gd2hvJ3MNCj4+IGFza2luZy4NCj4+DQo+PiBXZSBuZWVkIGJvdGgsIGFuZCB0 aGV5IG1heSB3ZWxsIHVzZSB0aGUgc2FtZSB3aXJlIHByb3RvY29sLCBidXQsIGlmDQo+PiB3ZSBo YXZlIHNvbWUga2luZCBvZiBwdWJsaWMgbnVtYmVyaW5nIGRhdGFiYXNlLCBpdCBjYW4ndCB0YWls b3IgaXRzDQo+PiByZXNwb25zZSB0byB0aGUgcXVlcmllciwgYnkgZGVmaW5pdGlvbi4NCj4+DQo+ PiBUbyBtYWtlIHRoaXMgYSBiaXQgbW9yZSBjb25jcmV0ZToNCj4+DQo+PiAoMSkgUXVlcnkgYSBw dWJsaWMgbnVtYmVyaW5nIGRhdGFiYXNlIHdpdGggdGhlIE1PREVSTiBwcm90b2NvbCwgd2l0aA0K Pj4gaW5wdXQgIm51bWJlciwgc2VydmljZSIuIEdldCBhIFNQSUQgb3IgZG9tYWluIG5hbWUsIHNh eSBtb2Rlcm4uYXR0Lm5ldC4NCj4+DQo+PiAoMikgUXVlcnkgZG9tYWluIG5hbWUgbW9kZXJuLmF0 dC5uZXQgd2l0aCBNT0RFUk4sIGJ1dCB3aXRoDQo+PiBhdXRoZW50aWNhdGlvbi4gUmV0dXJuIGN1 c3RvbWl6ZWQgU0lQIFVSTChzKS4gW0lmIHRoZSBxdWVyaWVyIGhhcyBubw0KPj4gcmVsYXRpb25z aGlwIHRvIG1vZGVybi5hdHQubmV0LCBpdCB3b3VsZCBwcmVzdW1hYmx5IGdldCBhIGdlbmVyaWMN Cj4+IGFuc3dlciBmb3IgY2FycmllcnMgd2l0aG91dCBzcGVjaWFsIGFycmFuZ2VtZW50IG9yIHNv bWUgdmVyc2lvbiBvZg0KPj4gImdvIGF3YXkiLl0NCj4+DQo+PiAoMykgVXNlIFJGQyAzMjYzIHBy b2Nlc3MgZm9yIHRob3NlIFVSTHMuDQo+Pg0KPj4gSXMgdGhhdCB3aGF0IHBlb3BsZSBoYXZlIGlu IG1pbmQ/DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gRnJvbTogQnJpYW4gUm9zZW4gW2JyQGJyaWFucm9zZW4ubmV0XQ0KPj4gU2VudDogTW9uZGF5 LCBPY3RvYmVyIDIwLCAyMDE0IDEwOjExIEFNDQo+PiBUbzogSGVubmluZyBTY2h1bHpyaW5uZQ0K Pj4gQ2M6IFJpY2hhcmQgU2hvY2tleTsgUEZBVVRaLCBQRU5OIEw7IEdvcm1hbiwgUGllcmNlIEEg W05US107DQo+PiBtb2Rlcm5AaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBTZXJ2 aWNlcw0KPj4NCj4+IE9rYXksIHBlcmhhcHMgd2UgYXJlLg0KPj4NCj4+IEkgdGhpbmsgwrNtZWRp YcKyIGlzIG5vdCBhIGdvb2Qgc2VydmljZSwgYnV0IHdlwrlsbCBzZWUuICBJIHRoaW5rIGl0wrlz DQo+PiBtb3JlIGxpa2Ugdm9pY2UvdmlkZW8vdGV4dC9ldmVudC4gIFRoZXkgY2FuIGFsd2F5cyBh bGwgaGF2ZSB0aGUgc2FtZSByZXNwb25zZS4NCj4+IEkgdGhpbmsgdGhhdCB1c2luZyBTUlYgaXMg bm90IGEgZ29vZCBlbm91Z2ggcm91dGluZyBwcm90b2NvbCwNCj4+IGFsdGhvdWdoIGFsbG93aW5n IGl0IHdvdWxkIGJlIGZpbmUgd2l0aCBtZS4gIFNSViwgbGlrZSBsb3RzIG9mDQo+PiB0aGluZ3Ms IGRvZXMgbm90IHByb3Blcmx5IGNvbnNpZGVyIHRoZSBzb3VyY2UsIG5vciB0aGUgbG9jYXRpb24s IGJvdGggcmVxdWlyZW1lbnRzLg0KPj4NCj4+IEl0IG1pZ2h0IGJlIG9rYXkgdG8gaGF2ZSBhIHR3 byBzdGVwIHJvdXRlIHdoZXJlIHRoZSBmaXJzdCBzdGVwDQo+PiByZXNvbHZlcyB0byBhIHJlbmRl enZvdXMgZm9yIG5lZ290aWF0aW9uIG9mIHRoZSBzaWduYWxpbmcgYW5kIG1lZGlhDQo+PiBpbnRl cmNoYW5nZSBwb2ludHMsIGJ1dCBJIHdvdWxkIHRoaW5rIHRoYXQgd291bGQgYmUgdGhlIHJlc3Vs dCBvZiB0aGUNCj4+IGZpcnN0IMKzbW9kZXJuwrIgcXVlcnkgPSBpdCByZXR1cm5zIGEgVVJJIHdo ZXJlIHlvdSBuZWdvdGlhdGUNCj4+IGludGVyY2hhbmdlLiAgVGhlIHNlY29uZCBzdGVwIHdvdWxk IGhhdmUgc29tZSBub3Rpb24gb2YgbG9jYXRpb24gYW5kDQo+PiBzb3VyY2UgaWRlbnRpdHkgYW5k IHJldHVybnMgcm91dGUuDQo+Pg0KPj4gQnJpYW4NCj4+DQo+Pg0KPj4+IE9uIE9jdCAyMCwgMjAx NCwgYXQgOTo1NyBBTSwgSGVubmluZyBTY2h1bHpyaW5uZQ0KPj4+IDxIZW5uaW5nLlNjaHVsenJp bm5lQGZjYy5nb3Y+IHdyb3RlOg0KPj4+DQo+Pj4gSSBzdXNwZWN0IHdlJ3JlIHRhbGtpbmcgcGFz dCBlYWNoIG90aGVyLiBJJ20gbm90IGFkdm9jYXRpbmcgYQ0KPj4+ICJnb2xkZW4gcm9vdCIgb3Ig YW55dGhpbmcgdGhhdCBsb29rcyBsaWtlIEVOVU0gbnVtYmVyLWJhc2VkIG1hcHBpbmcuDQo+Pj4g QXMgYSBzdHJhd21hbiwgY29uc2lkZXIgYSBKU09OIHJlc3BvbnNlIHdpdGhpbiB0aGUgTU9ERVJO IGNvbnRleHQgdG8NCj4+PiBhIHF1ZXJ5IGZvciBhIHBob25lIG51bWJlciwgcmV0dXJuaW5nIGZv ciB5b3UNCj4+Pg0KPj4+ICJtZWRpYSI6ICJteXBob25lLmJyaWFucm9zZW4ubmV0Ig0KPj4+DQo+ Pj4gd2l0aCBteXBob25lLmJyaWFucm9zZW4ubmV0DQo+Pj4NCj4+PiByZXNvbHZpbmcgdG8NCj4+ Pg0KPj4+IF9zaXAuX3RjcC5leGFtcGxlLmNvbS4gODY0MDAgSU4gU1JWIDAgNSA1MDYwIHNpcHNl cnZlci5leGFtcGxlLmNvbS4NCj4+Pg0KPj4+DQo+Pj4gSSBhc3N1bWUgd2UgZG9uJ3Qgd2FudCB0 byBwdXQgSVAgYWRkcmVzc2VzIGRpcmVjdGx5IGludG8gdGhlDQo+Pj4gcmVzcG9uc2UsIHNvIERO UyBlbnRlcnMgdGhlIHBpY3R1cmUgYXQgc29tZSBwb2ludC4NCj4+Pg0KPj4+IFRoZSBhbHRlcm5h dGl2ZSBpcyB0byB1c2UgdGhlIFNSViBvciBOQVBUUiBzZXJ2aWNlIGZpZWxkIChoZXJlLA0KPj4+ IF9zaXAuX3RjcCkgZGlyZWN0bHkgaW4gdGhlIE1PREVSTiByZXNwb25zZS4gSSBjYW4gc2VlIGFk dmFudGFnZXMgdG8gYm90aC4NCj4+Pg0KPj4+IEhlbm5pbmcNCj4+Pg0KPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBGcm9tOiBCcmlhbiBSb3NlbiBbYnJA YnJpYW5yb3Nlbi5uZXRdDQo+Pj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAyMDE0IDk6NTEg QU0NCj4+PiBUbzogSGVubmluZyBTY2h1bHpyaW5uZQ0KPj4+IENjOiBSaWNoYXJkIFNob2NrZXk7 IFBGQVVUWiwgUEVOTiBMOyBHb3JtYW4sIFBpZXJjZSBBIFtOVEtdOw0KPj4+IG1vZGVybkBpZXRm Lm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBTZXJ2aWNlcw0KPj4+DQo+Pj4gSSByZWFs bHkgd291bGQgbGlrZSB0byBnZXQgYXdheSBmcm9tIEROUyBlbnRpcmVseS4gIFdlIGNhbiByZXVz ZQ0KPj4+IGNvbmNlcHRzLCBidXQgSSB0aGluayBETlMgaXMgbm90IHRoZSBhcHByb3ByaWF0ZSB3 YXkgdG8gZ2V0IGFueXRoaW5nDQo+Pj4gdG8gZG8gd2l0aCBFLjE2NHMuDQo+Pj4gRU5VTSB3YXMg YSBtaXN0YWtlLCBhbmQgb25lIG9mIHRoZSBtaXN0YWtlcyB3YXMgdXNpbmcgRE5TLiAgSXTCuXMg bm90DQo+Pj4gdGhlIGFwcHJvcHJpYXRlIHF1ZXJ5IG1lY2hhbmlzbSwgYW5kIGl0IGhhcyBhIGdv bGRlbiByb290IHByb2JsZW0uDQo+Pj4gSSByZW1lbWJlciB3ZWxsIHRoZSBETlMgZ3V5cyBxdWVz dGlvbmluZyB3aGV0aGVyIEROUyB3YXMgdGhlIHJpZ2h0DQo+Pj4gcHJvdG9jb2wgd2hlbiB3ZSBz dGFydGVkIEVOVU0uICBXZSB3ZXJlIHNvIHN1cmUgaXQgd2FzLiAgSXQgd2FzIGENCj4+PiBtaXN0 YWtlIHRoZW4sIGFuZCBpdCBpcyBub3cuDQo+Pj4NCj4+PiBMZXTCuXMgbGVhcm4gZnJvbSB0aGF0 IGFuZCBzdGF5IGF3YXkgZnJvbSBETlMuDQo+Pj4NCj4+PiBXZSBuZWVkIGEgcXVlcnkgd2l0aCBU TiBhbmQgc2VydmljZSB0aGF0IHJldHVybnMgZWl0aGVyIHNvbWUgZm9ybSBvZg0KPj4+IHNlcnZp Y2UgcHJvdmlkZXIgaWQvc2VydmljZSBVUkwgYW5kL29yIHNvbWUgZm9ybSBvZiByb3V0ZS4gIEkN Cj4+PiBwZXJzb25hbGx5IHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYmVzdCB0byBrZWVwIHJvdXRl IHNlcGFyYXRlIGZyb20NCj4+PiBzZXJ2aWNlIHByb3ZpZGVyIGlkL1VSTCBiZWNhdXNlIEkgZG8g dGhpbmsgdGhlIHVzZXIgY29udHJvbHMgdGhhdA0KPj4+IHBhcnQgb2YgdGhlIHJlY29yZCB3aGls ZSB0aGUgU1AgY29udHJvbHMgdGhlIHJvdXRlLg0KPj4+DQo+Pj4gQnJpYW4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gTW9kZXJuIG1h aWxpbmcgbGlzdA0KPj4gTW9kZXJuQGlldGYub3JnDQo+PiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWkNCj4+IGxtYW5f DQo+PiBsaXN0aW5mb19tb2Rlcm4mZD1BQUlGLWcmYz1NT3B0TmxWdElFVGVEQUxDX2xVTHJ3JnI9 NEtsbTMyaUI3SHVmdmVlSUQNCj4+IGNMZXh0DQo+PiBaMW9vTmNmcDAxSVlJYVZxc09SakkmbT1w LUdYNDM4U2VLcjA1U3hGZTNpSTZQVU9Pd0RaSGdTUVA5ME1mUzVHTmpVJnMNCj4+ID0wWDkzIGFn UnEyelBhNWhoaTB6WHdBRndjUlJneDdqZ2tOUEpUQ3B1UldIYyZlPQ0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNb2Rlcm4gbWFpbGluZyBsaXN0 DQo+IE1vZGVybkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21vZGVybg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KTW9kZXJuIG1haWxpbmcgbGlzdA0KTW9kZXJuQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMp LiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxs IGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCg== From nobody Tue Oct 21 12:41:49 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FE01A1BCA for ; Tue, 21 Oct 2014 12:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 bcDC4xRLP1Pf for ; Tue, 21 Oct 2014 12:41:45 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFD71A1BD9 for ; Tue, 21 Oct 2014 12:41:44 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 7f6b6445.0.3979300.00-2166.11210858.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 21 Oct 2014 19:41:44 +0000 (UTC) X-MXL-Hash: 5446b6f859d222ee-86eb16922fa2dfdf2c821f7cd8712fd68ebc439d 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 s9LJfhcV012233 for ; Tue, 21 Oct 2014 15:41:43 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9LJfW8g012087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 21 Oct 2014 15:41:38 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Tue, 21 Oct 2014 19:41:23 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.34]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 15:41:23 -0400 From: "PFAUTZ, PENN L" To: "modern@ietf.org" Thread-Topic: Modern Digest, Vol 3, Issue 19 Thread-Index: AQHP7WGGiOiTQWPfSUCl5/Qfb+CYq5w68qqw Date: Tue, 21 Oct 2014 19:41:23 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D605742660@MISOUT7MSGUSRDD.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.157] Content-Type: multipart/mixed; boundary="_002_38726EDA2109264987B45E29E758C4D605742660MISOUT7MSGUSRDD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=MK7Xbrll c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=FDx_qJxh-vUA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=C7ZMsuyfnfJrEx3fy-gA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=uw9Sko2_AAAA:8 a=HZJGGiqLAAAA:8 a=HLLxP2VM] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=A1X0JdhQAAAA:8 a=RpNjiQI2AAAA:8 ] X-AnalysisOut: [a=yAkC8kDfzeSMa9WCpz4A:9 a=QEXdDO2ut3YA:10 a=-zy3ex45pM4A:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=l62ScjMGZ9dZWZUC:21 a=jy-AQe8VPoAOQ] X-AnalysisOut: [n0z:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/modern/eiDgvTce_lRqrzfEjOBr54XBT48 Subject: [Modern] FW: Modern Digest, Vol 3, Issue 19 X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:41:47 -0000 --_002_38726EDA2109264987B45E29E758C4D605742660MISOUT7MSGUSRDD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re Adam's issue below, I don't think some level of access control rules out= access by OTT. Recall that the FCC already trialed giving numbering resources directly to = OTT SPs. I'd distinguish between high barriers and reasonable obligations. Penn Hrm. I've heard OTT providers tossed around in this discussion as a=20 potential consumer of this data. It sounds like the last few messages=20 have been angling towards solutions that would provide high barriers to=20 entry to becoming such a provider. I'm thinking we should put some thought into how to deploy a system that=20 doesn't exclude small new players, while honoring the valid operational=20 concerns of incumbents. I'm very suspect of the naive approach of "well,=20 let's just make it a secret database that requires a special handshake=20 and/or the right amount of money to access." --_002_38726EDA2109264987B45E29E758C4D605742660MISOUT7MSGUSRDD_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 21 Oct 2014 19:02:13 GMT"; modification-date="Tue, 21 Oct 2014 19:02:13 GMT" Content-ID: From: Adam Roach To: "McGarry, Tom" , "modern@ietf.org" Subject: Re: [Modern] Services Thread-Topic: [Modern] Services Thread-Index: AQHP7WGGFax3o8mhdUeB6hFJJr7Oog== Date: Tue, 21 Oct 2014 18:07:00 +0000 Message-ID: <5446A0C4.4000704@nostrum.com> References: In-Reply-To: X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <2CB71CCCF8A0CA41A000163432DFE82E@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 SHJtLiBJJ3ZlIGhlYXJkIE9UVCBwcm92aWRlcnMgdG9zc2VkIGFyb3VuZCBpbiB0aGlzIGRpc2N1 c3Npb24gYXMgYQ0KcG90ZW50aWFsIGNvbnN1bWVyIG9mIHRoaXMgZGF0YS4gSXQgc291bmRzIGxp a2UgdGhlIGxhc3QgZmV3IG1lc3NhZ2VzDQpoYXZlIGJlZW4gYW5nbGluZyB0b3dhcmRzIHNvbHV0 aW9ucyB0aGF0IHdvdWxkIHByb3ZpZGUgaGlnaCBiYXJyaWVycyB0bw0KZW50cnkgdG8gYmVjb21p bmcgc3VjaCBhIHByb3ZpZGVyLg0KDQpJJ20gdGhpbmtpbmcgd2Ugc2hvdWxkIHB1dCBzb21lIHRo b3VnaHQgaW50byBob3cgdG8gZGVwbG95IGEgc3lzdGVtIHRoYXQNCmRvZXNuJ3QgZXhjbHVkZSBz bWFsbCBuZXcgcGxheWVycywgd2hpbGUgaG9ub3JpbmcgdGhlIHZhbGlkIG9wZXJhdGlvbmFsDQpj b25jZXJucyBvZiBpbmN1bWJlbnRzLiBJJ20gdmVyeSBzdXNwZWN0IG9mIHRoZSBuYWl2ZSBhcHBy b2FjaCBvZiAid2VsbCwNCmxldCdzIGp1c3QgbWFrZSBpdCBhIHNlY3JldCBkYXRhYmFzZSB0aGF0 IHJlcXVpcmVzIGEgc3BlY2lhbCBoYW5kc2hha2UNCmFuZC9vciB0aGUgcmlnaHQgYW1vdW50IG9m IG1vbmV5IHRvIGFjY2Vzcy4iDQoNCi9hDQoNCk9uIDEwLzIxLzE0IDEyOjQyLCBNY0dhcnJ5LCBU b20gd3JvdGU6DQo+IFNvIHRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgcHVzaGJhY2sgb24gYSAicHVi bGljIERCIiBhbmQgSSB0ZW5kIHRvIGFncmVlLg0KPiBUaGlzIGlzIHdoeSBJJ3ZlIGFkdm9jYXRl ZCB0aGF0IHRoZSBhZG1pbmlzdHJhdG9yIGRpc3RyaWJ1dGVzIHRoZXNlIERCcyB0bw0KPiBvdGhl cnMsIGUuZy4sIElTUHMuICBNYWtlIHRoZW0gcGFydCBvZiBzZXJ2aWNlIHByb3ZpZGVycycgaW5m cmFzdHJ1Y3R1cmUNCj4gd2l0aCBhbGwgdGhlIGF0dGVuZGFudCBzZWN1cml0eS4gIFRoZSBjaGFs bGVuZ2VzIGhlcmUgYXJlIGFyb3VuZCB1cGRhdGluZw0KPiBpdCBhbmQgc2VjdXJpbmcgdGhlIGRh dGEgZnJvbSB0aGUgZW50aXR5IHRoYXQgaXMgbm93IGhvc3RpbmcgaXQuICBTZWN1cmluZw0KPiBw cmltYXJpbHkgbWVhbnMgbWFraW5nIHN1cmUgaXQgY2FuJ3QgYmUgbW9kaWZpZWQuICBCdXQgaXQg Y291bGQgZXZlbiBtZWFuDQo+IHByb3RlY3RpbmcgaXQgZnJvbSBiZWluZyBtaW5lZC4NCj4NCj4N Cj4NCj4gT24gMTAvMjAvMTQgMTE6MzQgUE0sICJIZW5uaW5nIFNjaHVsenJpbm5lIiA8SGVubmlu Zy5TY2h1bHpyaW5uZUBmY2MuZ292Pg0KPiB3cm90ZToNCj4NCj4+IDxodG1sPg0KPj4gSSBzdXNw ZWN0IHdlJ3JlIHRyeWluZyB0byBnZXQgYXQgaG93IG1hbnkgbGV2ZWxzIG9mIGluZGlyZWN0aW9u IHdlIGFsbG93DQo+PiBiZWZvcmUgd2UgYXJyaXZlIGF0IFJGQyAzMjYzIGFuZCB3aGVyZSwgaW4g b25lIG9yIG1vcmUgcGxhY2VzLCBjaG9pY2VzIG9mDQo+PiBzZXJ2aWNlIGFyZSBleHByZXNzZWQu DQo+Pg0KPj4gV2hldGhlciB5b3UgZGVzaWduYXRlIGEgU1BJRCBvciBhIGRvbWFpbiBuYW1lLCB0 aGVyZSB0aGVuIGhhcyB0byBiZSBhDQo+PiBzZWNvbmQgc3RlcCB0byBnZXQgc29tZXRoaW5nIHJl c29sdmFibGUuIE5lZWRsZXNzIHRvIHNheSwgeW91IGNvdWxkIHVzZQ0KPj4gYm90aCwgc2luY2Ug YSBTUElEIHdvdWxkIHByZXN1bWFibHkgdHJhbnNsYXRlIG1lY2hhbmljYWxseSBpbnRvIGEgZG9t YWluDQo+PiBuYW1lIGxpa2UgMTIzNC5uZWNhLm9yZw0KPj4NCj4+IEFsc28sIEknbSBjb25mdXNl ZCBieSB0aGUgbW9kZWwgdGhhdCBwZW9wbGUgaGF2ZSBpbiBtaW5kIC0gd2Ugc2VlbSB0bw0KPj4g c2ltdWx0YW5lb3VzbHkgYmUgdGFsa2luZyBhYm91dCBpbmZvcm1hdGlvbiB0aGF0IGlzIGJlaW5n IHJldHVybmVkIGJ5IGENCj4+IHB1YmxpYyBudW1iZXIgZGlyZWN0b3J5IChiZWZvcmUgeW91IGtu b3cgd2hvIGlzICJpbiBjaGFyZ2UiIG9mIHRoZQ0KPj4gbnVtYmVyKSBhbmQgaGlnaGx5LWN1c3Rv bWl6ZWQgaW5mb3JtYXRpb24gdGhhdCBkaWZmZXJzIGJhc2VkIG9uIHdobydzDQo+PiBhc2tpbmcu DQo+Pg0KPj4gV2UgbmVlZCBib3RoLCBhbmQgdGhleSBtYXkgd2VsbCB1c2UgdGhlIHNhbWUgd2ly ZSBwcm90b2NvbCwgYnV0LCBpZiB3ZQ0KPj4gaGF2ZSBzb21lIGtpbmQgb2YgcHVibGljIG51bWJl cmluZyBkYXRhYmFzZSwgaXQgY2FuJ3QgdGFpbG9yIGl0cyByZXNwb25zZQ0KPj4gdG8gdGhlIHF1 ZXJpZXIsIGJ5IGRlZmluaXRpb24uDQo+Pg0KPj4gVG8gbWFrZSB0aGlzIGEgYml0IG1vcmUgY29u Y3JldGU6DQo+Pg0KPj4gKDEpIFF1ZXJ5IGEgcHVibGljIG51bWJlcmluZyBkYXRhYmFzZSB3aXRo IHRoZSBNT0RFUk4gcHJvdG9jb2wsIHdpdGgNCj4+IGlucHV0ICJudW1iZXIsIHNlcnZpY2UiLiBH ZXQgYSBTUElEIG9yIGRvbWFpbiBuYW1lLCBzYXkgbW9kZXJuLmF0dC5uZXQuDQo+Pg0KPj4gKDIp IFF1ZXJ5IGRvbWFpbiBuYW1lIG1vZGVybi5hdHQubmV0IHdpdGggTU9ERVJOLCBidXQgd2l0aA0K Pj4gYXV0aGVudGljYXRpb24uIFJldHVybiBjdXN0b21pemVkIFNJUCBVUkwocykuIFtJZiB0aGUg cXVlcmllciBoYXMgbm8NCj4+IHJlbGF0aW9uc2hpcCB0byBtb2Rlcm4uYXR0Lm5ldCwgaXQgd291 bGQgcHJlc3VtYWJseSBnZXQgYSBnZW5lcmljIGFuc3dlcg0KPj4gZm9yIGNhcnJpZXJzIHdpdGhv dXQgc3BlY2lhbCBhcnJhbmdlbWVudCBvciBzb21lIHZlcnNpb24gb2YgImdvIGF3YXkiLl0NCj4+ DQo+PiAoMykgVXNlIFJGQyAzMjYzIHByb2Nlc3MgZm9yIHRob3NlIFVSTHMuDQo+Pg0KPj4gSXMg dGhhdCB3aGF0IHBlb3BsZSBoYXZlIGluIG1pbmQ/DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gRnJvbTogQnJpYW4gUm9zZW4gW2JyQGJyaWFucm9z ZW4ubmV0XQ0KPj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDIwLCAyMDE0IDEwOjExIEFNDQo+PiBU bzogSGVubmluZyBTY2h1bHpyaW5uZQ0KPj4gQ2M6IFJpY2hhcmQgU2hvY2tleTsgUEZBVVRaLCBQ RU5OIEw7IEdvcm1hbiwgUGllcmNlIEEgW05US107DQo+PiBtb2Rlcm5AaWV0Zi5vcmcNCj4+IFN1 YmplY3Q6IFJlOiBbTW9kZXJuXSBTZXJ2aWNlcw0KPj4NCj4+IE9rYXksIHBlcmhhcHMgd2UgYXJl Lg0KPj4NCj4+IEkgdGhpbmsgwrNtZWRpYcKyIGlzIG5vdCBhIGdvb2Qgc2VydmljZSwgYnV0IHdl wrlsbCBzZWUuICBJIHRoaW5rIGl0wrlzIG1vcmUNCj4+IGxpa2Ugdm9pY2UvdmlkZW8vdGV4dC9l dmVudC4gIFRoZXkgY2FuIGFsd2F5cyBhbGwgaGF2ZSB0aGUgc2FtZSByZXNwb25zZS4NCj4+IEkg dGhpbmsgdGhhdCB1c2luZyBTUlYgaXMgbm90IGEgZ29vZCBlbm91Z2ggcm91dGluZyBwcm90b2Nv bCwgYWx0aG91Z2gNCj4+IGFsbG93aW5nIGl0IHdvdWxkIGJlIGZpbmUgd2l0aCBtZS4gIFNSViwg bGlrZSBsb3RzIG9mIHRoaW5ncywgZG9lcyBub3QNCj4+IHByb3Blcmx5IGNvbnNpZGVyIHRoZSBz b3VyY2UsIG5vciB0aGUgbG9jYXRpb24sIGJvdGggcmVxdWlyZW1lbnRzLg0KPj4NCj4+IEl0IG1p Z2h0IGJlIG9rYXkgdG8gaGF2ZSBhIHR3byBzdGVwIHJvdXRlIHdoZXJlIHRoZSBmaXJzdCBzdGVw IHJlc29sdmVzDQo+PiB0byBhIHJlbmRlenZvdXMgZm9yIG5lZ290aWF0aW9uIG9mIHRoZSBzaWdu YWxpbmcgYW5kIG1lZGlhIGludGVyY2hhbmdlDQo+PiBwb2ludHMsIGJ1dCBJIHdvdWxkIHRoaW5r IHRoYXQgd291bGQgYmUgdGhlIHJlc3VsdCBvZiB0aGUgZmlyc3QgwrNtb2Rlcm7Csg0KPj4gcXVl cnkgPSBpdCByZXR1cm5zIGEgVVJJIHdoZXJlIHlvdSBuZWdvdGlhdGUgaW50ZXJjaGFuZ2UuICBU aGUgc2Vjb25kDQo+PiBzdGVwIHdvdWxkIGhhdmUgc29tZSBub3Rpb24gb2YgbG9jYXRpb24gYW5k IHNvdXJjZSBpZGVudGl0eSBhbmQgcmV0dXJucw0KPj4gcm91dGUuDQo+Pg0KPj4gQnJpYW4NCj4+ DQo+Pg0KPj4+IE9uIE9jdCAyMCwgMjAxNCwgYXQgOTo1NyBBTSwgSGVubmluZyBTY2h1bHpyaW5u ZQ0KPj4+IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+IHdyb3RlOg0KPj4+DQo+Pj4gSSBz dXNwZWN0IHdlJ3JlIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVyLiBJJ20gbm90IGFkdm9jYXRpbmcg YSAiZ29sZGVuDQo+Pj4gcm9vdCIgb3IgYW55dGhpbmcgdGhhdCBsb29rcyBsaWtlIEVOVU0gbnVt YmVyLWJhc2VkIG1hcHBpbmcuIEFzIGENCj4+PiBzdHJhd21hbiwgY29uc2lkZXIgYSBKU09OIHJl c3BvbnNlIHdpdGhpbiB0aGUgTU9ERVJOIGNvbnRleHQgdG8gYSBxdWVyeQ0KPj4+IGZvciBhIHBo b25lIG51bWJlciwgcmV0dXJuaW5nIGZvciB5b3UNCj4+Pg0KPj4+ICJtZWRpYSI6ICJteXBob25l LmJyaWFucm9zZW4ubmV0Ig0KPj4+DQo+Pj4gd2l0aCBteXBob25lLmJyaWFucm9zZW4ubmV0DQo+ Pj4NCj4+PiByZXNvbHZpbmcgdG8NCj4+Pg0KPj4+IF9zaXAuX3RjcC5leGFtcGxlLmNvbS4gODY0 MDAgSU4gU1JWIDAgNSA1MDYwIHNpcHNlcnZlci5leGFtcGxlLmNvbS4NCj4+Pg0KPj4+DQo+Pj4g SSBhc3N1bWUgd2UgZG9uJ3Qgd2FudCB0byBwdXQgSVAgYWRkcmVzc2VzIGRpcmVjdGx5IGludG8g dGhlIHJlc3BvbnNlLA0KPj4+IHNvIEROUyBlbnRlcnMgdGhlIHBpY3R1cmUgYXQgc29tZSBwb2lu dC4NCj4+Pg0KPj4+IFRoZSBhbHRlcm5hdGl2ZSBpcyB0byB1c2UgdGhlIFNSViBvciBOQVBUUiBz ZXJ2aWNlIGZpZWxkIChoZXJlLA0KPj4+IF9zaXAuX3RjcCkgZGlyZWN0bHkgaW4gdGhlIE1PREVS TiByZXNwb25zZS4gSSBjYW4gc2VlIGFkdmFudGFnZXMgdG8gYm90aC4NCj4+Pg0KPj4+IEhlbm5p bmcNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBGcm9tOiBCcmlhbiBSb3NlbiBbYnJAYnJpYW5yb3Nlbi5uZXRdDQo+Pj4gU2VudDogTW9uZGF5 LCBPY3RvYmVyIDIwLCAyMDE0IDk6NTEgQU0NCj4+PiBUbzogSGVubmluZyBTY2h1bHpyaW5uZQ0K Pj4+IENjOiBSaWNoYXJkIFNob2NrZXk7IFBGQVVUWiwgUEVOTiBMOyBHb3JtYW4sIFBpZXJjZSBB IFtOVEtdOw0KPj4+IG1vZGVybkBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbTW9kZXJuXSBT ZXJ2aWNlcw0KPj4+DQo+Pj4gSSByZWFsbHkgd291bGQgbGlrZSB0byBnZXQgYXdheSBmcm9tIERO UyBlbnRpcmVseS4gIFdlIGNhbiByZXVzZQ0KPj4+IGNvbmNlcHRzLCBidXQgSSB0aGluayBETlMg aXMgbm90IHRoZSBhcHByb3ByaWF0ZSB3YXkgdG8gZ2V0IGFueXRoaW5nIHRvDQo+Pj4gZG8gd2l0 aCBFLjE2NHMuDQo+Pj4gRU5VTSB3YXMgYSBtaXN0YWtlLCBhbmQgb25lIG9mIHRoZSBtaXN0YWtl cyB3YXMgdXNpbmcgRE5TLiAgSXTCuXMgbm90DQo+Pj4gdGhlIGFwcHJvcHJpYXRlIHF1ZXJ5IG1l Y2hhbmlzbSwgYW5kIGl0IGhhcyBhIGdvbGRlbiByb290IHByb2JsZW0uICBJDQo+Pj4gcmVtZW1i ZXIgd2VsbCB0aGUgRE5TIGd1eXMgcXVlc3Rpb25pbmcgd2hldGhlciBETlMgd2FzIHRoZSByaWdo dA0KPj4+IHByb3RvY29sIHdoZW4gd2Ugc3RhcnRlZCBFTlVNLiAgV2Ugd2VyZSBzbyBzdXJlIGl0 IHdhcy4gIEl0IHdhcyBhDQo+Pj4gbWlzdGFrZSB0aGVuLCBhbmQgaXQgaXMgbm93Lg0KPj4+DQo+ Pj4gTGV0wrlzIGxlYXJuIGZyb20gdGhhdCBhbmQgc3RheSBhd2F5IGZyb20gRE5TLg0KPj4+DQo+ Pj4gV2UgbmVlZCBhIHF1ZXJ5IHdpdGggVE4gYW5kIHNlcnZpY2UgdGhhdCByZXR1cm5zIGVpdGhl ciBzb21lIGZvcm0gb2YNCj4+PiBzZXJ2aWNlIHByb3ZpZGVyIGlkL3NlcnZpY2UgVVJMIGFuZC9v ciBzb21lIGZvcm0gb2Ygcm91dGUuICBJIHBlcnNvbmFsbHkNCj4+PiB0aGluayB0aGF0IGl0IHdv dWxkIGJlIGJlc3QgdG8ga2VlcCByb3V0ZSBzZXBhcmF0ZSBmcm9tIHNlcnZpY2UgcHJvdmlkZXIN Cj4+PiBpZC9VUkwgYmVjYXVzZSBJIGRvIHRoaW5rIHRoZSB1c2VyIGNvbnRyb2xzIHRoYXQgcGFy dCBvZiB0aGUgcmVjb3JkDQo+Pj4gd2hpbGUgdGhlIFNQIGNvbnRyb2xzIHRoZSByb3V0ZS4NCj4+ Pg0KPj4+IEJyaWFuDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IE1vZGVybiBtYWlsaW5nIGxpc3QNCj4+IE1vZGVybkBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl8NCj4+IGxpc3RpbmZvX21vZGVybiZkPUFBSUYtZyZjPU1PcHRO bFZ0SUVUZURBTENfbFVMcncmcj00S2xtMzJpQjdIdWZ2ZWVJRGNMZXh0DQo+PiBaMW9vTmNmcDAx SVlJYVZxc09SakkmbT1wLUdYNDM4U2VLcjA1U3hGZTNpSTZQVU9Pd0RaSGdTUVA5ME1mUzVHTmpV JnM9MFg5Mw0KPj4gYWdScTJ6UGE1aGhpMHpYd0FGd2NSUmd4N2pna05QSlRDcHVSV0hjJmU9DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1vZGVy biBtYWlsaW5nIGxpc3QNCj4gTW9kZXJuQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW9kZXJuDQoNCg0K --_002_38726EDA2109264987B45E29E758C4D605742660MISOUT7MSGUSRDD_-- From nobody Tue Oct 21 12:43:10 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5051A1A25 for ; Tue, 21 Oct 2014 12:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URI_TRY_3LD=0.001] autolearn=ham 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 0N9npx1D9kzY for ; Tue, 21 Oct 2014 12:43:05 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52B11A1BDB for ; Tue, 21 Oct 2014 12:43:04 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id dc16so1363166qab.25 for ; Tue, 21 Oct 2014 12:43:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zubYzBHL1W/PuHF29W2au0S3QI32jhFrQ78jBnsJe7w=; b=gWTwARwyMaexbYCsommmSG8jKqbgc8oITzhmahuVX+r4KEOSRmz1/VtQnbMAtLSnyC ORIPt+e5RJpBfJ/2G380jbxa4QP7kEvna/u2DUMJDZALA55nx4zUsQo9asB7UfzyDRUG 2ApiYivANUGTwqEQvbYdK+THzE1zqp1F7P8IL/a4yfgFKIOqbez+wTVfEsS37d4I7avz uuWxn0kx6/hGLdaUguaWVvxour9LIZYWTtG2HjuZYplADW7J868+lUEAjWi8u4Y/DVfd Z2HOa7K877eevhfa4VLuHXJUt0Js1EeAJesdD4/ZBqUbPGpOARaTL6Ud/8UP+RvUuJkQ WC/g== X-Gm-Message-State: ALoCoQlWyQdL31igLCuGVqPcCiVXo5gKw9KNy/tnheAU7ofqP1oPBVmxgqsdZ1EFL1p9LhujoZBe X-Received: by 10.140.40.99 with SMTP id w90mr45880304qgw.18.1413920582468; Tue, 21 Oct 2014 12:43:02 -0700 (PDT) Received: from [10.33.192.28] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id r1sm4193450qam.30.2014.10.21.12.43.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 12:43:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brian Rosen In-Reply-To: <5446A0C4.4000704@nostrum.com> Date: Tue, 21 Oct 2014 15:43:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4BAE54B3-AC73-4E87-BBC2-EFD9F7560C94@brianrosen.net> References: <5446A0C4.4000704@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/modern/oMpGbVx_QOftvBAKweSda5jcb4A Cc: "modern@ietf.org" , "McGarry, Tom" Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:43:09 -0000 Clearly, we need a low barrier to entry. It=E2=80=99s not clear there = should be no barrier. =E2=80=9CPeering=E2=80=9D might be the way in. If you have an agreement = to peer with someone, you can get at the database. Seed with the = current notion of carrier and it might scale from there. Brian Brian > On Oct 21, 2014, at 2:07 PM, Adam Roach wrote: >=20 > Hrm. I've heard OTT providers tossed around in this discussion as a = potential consumer of this data. It sounds like the last few messages = have been angling towards solutions that would provide high barriers to = entry to becoming such a provider. >=20 > I'm thinking we should put some thought into how to deploy a system = that doesn't exclude small new players, while honoring the valid = operational concerns of incumbents. I'm very suspect of the naive = approach of "well, let's just make it a secret database that requires a = special handshake and/or the right amount of money to access." >=20 > /a >=20 > On 10/21/14 12:42, McGarry, Tom wrote: >> So there seems to be some pushback on a "public DB" and I tend to = agree. >> This is why I've advocated that the administrator distributes these = DBs to >> others, e.g., ISPs. Make them part of service providers' = infrastructure >> with all the attendant security. The challenges here are around = updating >> it and securing the data from the entity that is now hosting it. = Securing >> primarily means making sure it can't be modified. But it could even = mean >> protecting it from being mined. >>=20 >> =20 >> On 10/20/14 11:34 PM, "Henning Schulzrinne" = >> wrote: >>=20 >>> >>> I suspect we're trying to get at how many levels of indirection we = allow >>> before we arrive at RFC 3263 and where, in one or more places, = choices of >>> service are expressed. >>>=20 >>> Whether you designate a SPID or a domain name, there then has to be = a >>> second step to get something resolvable. Needless to say, you could = use >>> both, since a SPID would presumably translate mechanically into a = domain >>> name like 1234.neca.org >>>=20 >>> Also, I'm confused by the model that people have in mind - we seem = to >>> simultaneously be talking about information that is being returned = by a >>> public number directory (before you know who is "in charge" of the >>> number) and highly-customized information that differs based on = who's >>> asking. >>>=20 >>> We need both, and they may well use the same wire protocol, but, if = we >>> have some kind of public numbering database, it can't tailor its = response >>> to the querier, by definition. >>>=20 >>> To make this a bit more concrete: >>>=20 >>> (1) Query a public numbering database with the MODERN protocol, with >>> input "number, service". Get a SPID or domain name, say = modern.att.net. >>>=20 >>> (2) Query domain name modern.att.net with MODERN, but with >>> authentication. Return customized SIP URL(s). [If the querier has no >>> relationship to modern.att.net, it would presumably get a generic = answer >>> for carriers without special arrangement or some version of "go = away".] >>>=20 >>> (3) Use RFC 3263 process for those URLs. >>>=20 >>> Is that what people have in mind? >>>=20 >>> ________________________________________ >>> From: Brian Rosen [br@brianrosen.net] >>> Sent: Monday, October 20, 2014 10:11 AM >>> To: Henning Schulzrinne >>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>> modern@ietf.org >>> Subject: Re: [Modern] Services >>>=20 >>> Okay, perhaps we are. >>>=20 >>> I think =C2=B3media=C2=B2 is not a good service, but we=C2=B9ll see. = I think it=C2=B9s more >>> like voice/video/text/event. They can always all have the same = response. >>> I think that using SRV is not a good enough routing protocol, = although >>> allowing it would be fine with me. SRV, like lots of things, does = not >>> properly consider the source, nor the location, both requirements. >>>=20 >>> It might be okay to have a two step route where the first step = resolves >>> to a rendezvous for negotiation of the signaling and media = interchange >>> points, but I would think that would be the result of the first = =C2=B3modern=C2=B2 >>> query =3D it returns a URI where you negotiate interchange. The = second >>> step would have some notion of location and source identity and = returns >>> route. >>>=20 >>> Brian >>>=20 >>>=20 >>>> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne >>>> wrote: >>>>=20 >>>> I suspect we're talking past each other. I'm not advocating a = "golden >>>> root" or anything that looks like ENUM number-based mapping. As a >>>> strawman, consider a JSON response within the MODERN context to a = query >>>> for a phone number, returning for you >>>>=20 >>>> "media": "myphone.brianrosen.net" >>>>=20 >>>> with myphone.brianrosen.net >>>>=20 >>>> resolving to >>>>=20 >>>> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>>>=20 >>>>=20 >>>> I assume we don't want to put IP addresses directly into the = response, >>>> so DNS enters the picture at some point. >>>>=20 >>>> The alternative is to use the SRV or NAPTR service field (here, >>>> _sip._tcp) directly in the MODERN response. I can see advantages to = both. >>>>=20 >>>> Henning >>>>=20 >>>> ________________________________________ >>>> From: Brian Rosen [br@brianrosen.net] >>>> Sent: Monday, October 20, 2014 9:51 AM >>>> To: Henning Schulzrinne >>>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>>> modern@ietf.org >>>> Subject: Re: [Modern] Services >>>>=20 >>>> I really would like to get away from DNS entirely. We can reuse >>>> concepts, but I think DNS is not the appropriate way to get = anything to >>>> do with E.164s. >>>> ENUM was a mistake, and one of the mistakes was using DNS. It=C2=B9s= not >>>> the appropriate query mechanism, and it has a golden root problem. = I >>>> remember well the DNS guys questioning whether DNS was the right >>>> protocol when we started ENUM. We were so sure it was. It was a >>>> mistake then, and it is now. >>>>=20 >>>> Let=C2=B9s learn from that and stay away from DNS. >>>>=20 >>>> We need a query with TN and service that returns either some form = of >>>> service provider id/service URL and/or some form of route. I = personally >>>> think that it would be best to keep route separate from service = provider >>>> id/URL because I do think the user controls that part of the record >>>> while the SP controls the route. >>>>=20 >>>> Brian >>>=20 >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >>> = listinfo_modern&d=3DAAIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >>> = Z1ooNcfp01IYIaVqsORjI&m=3Dp-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s=3D= 0X93 >>> agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e=3D >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >> https://www.ietf.org/mailman/listinfo/modern >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern From nobody Tue Oct 21 12:52:40 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF521A3B9E for ; Tue, 21 Oct 2014 12:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.616 X-Spam-Level: X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 aQXyLoFlYvm5 for ; Tue, 21 Oct 2014 12:52:27 -0700 (PDT) Received: from mia.egh.com (50-79-181-89-static.hfc.comcastbusiness.net [50.79.181.89]) (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 A7DA71A3BA3 for ; Tue, 21 Oct 2014 12:52:25 -0700 (PDT) Received: from [198.179.132.36] (Cortland.egh.com [198.179.132.36]) by mia.egh.com (8.14.5/8.14.5/SuSE Linux 0.8) with ESMTP id s9LJqNk0026130; Tue, 21 Oct 2014 15:52:23 -0400 User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Tue, 21 Oct 2014 15:52:22 -0400 From: Ken Pogran To: "McGarry, Tom" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Services In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/modern/MyVTwQl0xfKez5tLUh9exLG7ib8 Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 19:52:30 -0000 The notion of not having a single public database, but instead having databases maintained by multiple service providers, is akin to what we have today with the PSTN's LIDB/CNAM databases. So this is a model that is familiar to service providers. Provisioning of these databases (by SPs, imbuing the data provisioned with some level of trust), is also well understood. (There is, of course, the question of whether the database maintained by each service provider contains all TNs, or if the space is somehow partitioned, as with today's LIDB/CNAM). Today's PSTN databases live on the SS7 network, which for the most part is a closed network that also affords some degree of "security by obscurity." The databases we're talking about here won't have that, umm, "advantage" and so will need more explicit security mechanisms. We will need to explore a variety of use cases. Perhaps we will have the equivalent of "listed" and "unlisted" numbers, where information about certain services is publicly available for listed numbers, while the same information is unavailable for unlisted numbers. Since there will be many services associated with a telephone number, we will need to define WHAT entities are entitled to query WHOSE databases about WHICH service entries for a given TN (e.g., Henning's "who's asking?"). Use cases will help us explore this. Ken Pogran EGH www.egh.com On 10/21/14 1:42 PM, "McGarry, Tom" wrote: >So there seems to be some pushback on a "public DB" and I tend to agree. >This is why I've advocated that the administrator distributes these DBs to >others, e.g., ISPs. Make them part of service providers' infrastructure >with all the attendant security. The challenges here are around updating >it and securing the data from the entity that is now hosting it. Securing >primarily means making sure it can't be modified. But it could even mean >protecting it from being mined. > > > >On 10/20/14 11:34 PM, "Henning Schulzrinne" >wrote: > >> >>I suspect we're trying to get at how many levels of indirection we allow >>before we arrive at RFC 3263 and where, in one or more places, choices of >>service are expressed. >> >>Whether you designate a SPID or a domain name, there then has to be a >>second step to get something resolvable. Needless to say, you could use >>both, since a SPID would presumably translate mechanically into a domain >>name like 1234.neca.org >> >>Also, I'm confused by the model that people have in mind - we seem to >>simultaneously be talking about information that is being returned by a >>public number directory (before you know who is "in charge" of the >>number) and highly-customized information that differs based on who's >>asking. >> >>We need both, and they may well use the same wire protocol, but, if we >>have some kind of public numbering database, it can't tailor its response >>to the querier, by definition. >> >>To make this a bit more concrete: >> >>(1) Query a public numbering database with the MODERN protocol, with >>input "number, service". Get a SPID or domain name, say modern.att.net. >> >>(2) Query domain name modern.att.net with MODERN, but with >>authentication. Return customized SIP URL(s). [If the querier has no >>relationship to modern.att.net, it would presumably get a generic answer >>for carriers without special arrangement or some version of "go away".] >> >>(3) Use RFC 3263 process for those URLs. >> >>Is that what people have in mind? From nobody Tue Oct 21 22:00:23 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874591A8AA1 for ; Tue, 21 Oct 2014 22:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 OFCI9a93mPMJ for ; Tue, 21 Oct 2014 22:00:19 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC251A8A9D for ; Tue, 21 Oct 2014 22:00:18 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [NTK]" , Adam Roach , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGs Date: Wed, 22 Oct 2014 05:00:15 +0000 References: <5446A0C4.4000704@nostrum.com>, <9a0e4d630a154c0db8d4dad3039fd455@PLSWE13M08.ad.sprint.com> In-Reply-To: <9a0e4d630a154c0db8d4dad3039fd455@PLSWE13M08.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/fXToXu68pJH-YRrMLQDW7eMsTwE Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:00:22 -0000 Let's assume for a moment that organizations can directly get numbers, e.g.= , a university or corporation. Why shouldn't they be able to advertise thei= r direct reachability and other characteristics, via (say) SIP, just as the= y advertise their BGP or DNS reachability today?=0A= =0A= Whether to do that is obviously a policy decision, but I suspect it's wise = to plan for the ability of a large number of entities to acquire numbers, w= hether that number is 100 million households, 6 million businesses (with em= ployees) or 6,000 (guestimate) of carriers and kind-of-like-carriers entiti= es.=0A= =0A= I suspect we mostly agree that there may not be a single master copy that e= verybody accesses, but rather physically (and logically) distributed, but s= ynchronized, versions.=0A= =0A= Going back to the compatibility and learning from other public identifier s= ystems, what aspects of the DNS environment (not the protocol) are importan= t to clone and which have shown themselves to be problematic?=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A [NTK] = [Pierce.Gorman@sprint.com]=0A= Sent: Tuesday, October 21, 2014 3:15 PM=0A= To: Adam Roach; McGarry, Tom; modern@ietf.org=0A= Subject: Re: [Modern] Services=0A= =0A= LERG and NPAC may fall into your categories of na=EFve, secret, requiring a= special handshake, and right amount of money to access, but I would argue = with na=EFve. :-)=0A= =0A= Your concern is still valid and I agree. Slamming has been a problem in th= e past even with controlled access. Perhaps database content of services/S= P associated with TN(s) associated with a typical consumer subscriber can b= e controlled by the subscriber themselves? They do so through the proxy of= their telephone service carrier(s) today, but MODERN technology (pun inten= ded) might support a more direct role.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Voice Architecture=0A= Core Planning/Sprint=0A= 913-439-4368 (Desk)=0A= =0A= =0A= -----Original Message-----=0A= From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach=0A= Sent: October 21, 2014 1:07 PM=0A= To: McGarry, Tom; modern@ietf.org=0A= Subject: Re: [Modern] Services=0A= =0A= Hrm. I've heard OTT providers tossed around in this discussion as a potenti= al consumer of this data. It sounds like the last few messages have been an= gling towards solutions that would provide high barriers to entry to becomi= ng such a provider.=0A= =0A= I'm thinking we should put some thought into how to deploy a system that do= esn't exclude small new players, while honoring the valid operational conce= rns of incumbents. I'm very suspect of the naive approach of "well, let's j= ust make it a secret database that requires a special handshake and/or the = right amount of money to access."=0A= =0A= /a=0A= =0A= On 10/21/14 12:42, McGarry, Tom wrote:=0A= > So there seems to be some pushback on a "public DB" and I tend to agree.= =0A= > This is why I've advocated that the administrator distributes these=0A= > DBs to others, e.g., ISPs. Make them part of service providers'=0A= > infrastructure with all the attendant security. The challenges here=0A= > are around updating it and securing the data from the entity that is=0A= > now hosting it. Securing primarily means making sure it can't be=0A= > modified. But it could even mean protecting it from being mined.=0A= >=0A= >=0A= >=0A= > On 10/20/14 11:34 PM, "Henning Schulzrinne"=0A= > =0A= > wrote:=0A= >=0A= >> =0A= >> I suspect we're trying to get at how many levels of indirection we=0A= >> allow before we arrive at RFC 3263 and where, in one or more places,=0A= >> choices of service are expressed.=0A= >>=0A= >> Whether you designate a SPID or a domain name, there then has to be a=0A= >> second step to get something resolvable. Needless to say, you could=0A= >> use both, since a SPID would presumably translate mechanically into a=0A= >> domain name like 1234.neca.org=0A= >>=0A= >> Also, I'm confused by the model that people have in mind - we seem to=0A= >> simultaneously be talking about information that is being returned by=0A= >> a public number directory (before you know who is "in charge" of the=0A= >> number) and highly-customized information that differs based on who's=0A= >> asking.=0A= >>=0A= >> We need both, and they may well use the same wire protocol, but, if=0A= >> we have some kind of public numbering database, it can't tailor its=0A= >> response to the querier, by definition.=0A= >>=0A= >> To make this a bit more concrete:=0A= >>=0A= >> (1) Query a public numbering database with the MODERN protocol, with=0A= >> input "number, service". Get a SPID or domain name, say modern.att.net.= =0A= >>=0A= >> (2) Query domain name modern.att.net with MODERN, but with=0A= >> authentication. Return customized SIP URL(s). [If the querier has no=0A= >> relationship to modern.att.net, it would presumably get a generic=0A= >> answer for carriers without special arrangement or some version of=0A= >> "go away".]=0A= >>=0A= >> (3) Use RFC 3263 process for those URLs.=0A= >>=0A= >> Is that what people have in mind?=0A= >>=0A= >> ________________________________________=0A= >> From: Brian Rosen [br@brianrosen.net]=0A= >> Sent: Monday, October 20, 2014 10:11 AM=0A= >> To: Henning Schulzrinne=0A= >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK];=0A= >> modern@ietf.org=0A= >> Subject: Re: [Modern] Services=0A= >>=0A= >> Okay, perhaps we are.=0A= >>=0A= >> I think =B3media=B2 is not a good service, but we=B9ll see. I think it= =B9s=0A= >> more like voice/video/text/event. They can always all have the same res= ponse.=0A= >> I think that using SRV is not a good enough routing protocol,=0A= >> although allowing it would be fine with me. SRV, like lots of=0A= >> things, does not properly consider the source, nor the location, both re= quirements.=0A= >>=0A= >> It might be okay to have a two step route where the first step=0A= >> resolves to a rendezvous for negotiation of the signaling and media=0A= >> interchange points, but I would think that would be the result of the=0A= >> first =B3modern=B2 query =3D it returns a URI where you negotiate=0A= >> interchange. The second step would have some notion of location and=0A= >> source identity and returns route.=0A= >>=0A= >> Brian=0A= >>=0A= >>=0A= >>> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne=0A= >>> wrote:=0A= >>>=0A= >>> I suspect we're talking past each other. I'm not advocating a=0A= >>> "golden root" or anything that looks like ENUM number-based mapping.=0A= >>> As a strawman, consider a JSON response within the MODERN context to=0A= >>> a query for a phone number, returning for you=0A= >>>=0A= >>> "media": "myphone.brianrosen.net"=0A= >>>=0A= >>> with myphone.brianrosen.net=0A= >>>=0A= >>> resolving to=0A= >>>=0A= >>> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.=0A= >>>=0A= >>>=0A= >>> I assume we don't want to put IP addresses directly into the=0A= >>> response, so DNS enters the picture at some point.=0A= >>>=0A= >>> The alternative is to use the SRV or NAPTR service field (here,=0A= >>> _sip._tcp) directly in the MODERN response. I can see advantages to bot= h.=0A= >>>=0A= >>> Henning=0A= >>>=0A= >>> ________________________________________=0A= >>> From: Brian Rosen [br@brianrosen.net]=0A= >>> Sent: Monday, October 20, 2014 9:51 AM=0A= >>> To: Henning Schulzrinne=0A= >>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK];=0A= >>> modern@ietf.org=0A= >>> Subject: Re: [Modern] Services=0A= >>>=0A= >>> I really would like to get away from DNS entirely. We can reuse=0A= >>> concepts, but I think DNS is not the appropriate way to get anything=0A= >>> to do with E.164s.=0A= >>> ENUM was a mistake, and one of the mistakes was using DNS. It=B9s not= =0A= >>> the appropriate query mechanism, and it has a golden root problem.=0A= >>> I remember well the DNS guys questioning whether DNS was the right=0A= >>> protocol when we started ENUM. We were so sure it was. It was a=0A= >>> mistake then, and it is now.=0A= >>>=0A= >>> Let=B9s learn from that and stay away from DNS.=0A= >>>=0A= >>> We need a query with TN and service that returns either some form of=0A= >>> service provider id/service URL and/or some form of route. I=0A= >>> personally think that it would be best to keep route separate from=0A= >>> service provider id/URL because I do think the user controls that=0A= >>> part of the record while the SP controls the route.=0A= >>>=0A= >>> Brian=0A= >>=0A= >> _______________________________________________=0A= >> Modern mailing list=0A= >> Modern@ietf.org=0A= >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= =0A= >> lman_=0A= >> listinfo_modern&d=3DAAIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eID=0A= >> cLext=0A= >> Z1ooNcfp01IYIaVqsORjI&m=3Dp-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s= =0A= >> =3D0X93 agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e=3D=0A= > _______________________________________________=0A= > Modern mailing list=0A= > Modern@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/modern=0A= =0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= _______________________________________________=0A= Modern mailing list=0A= Modern@ietf.org=0A= https://www.ietf.org/mailman/listinfo/modern=0A= From nobody Tue Oct 21 22:09:52 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A558E1A8AAF for ; Tue, 21 Oct 2014 22:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URI_TRY_3LD=0.001] autolearn=ham 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 WZaXd1U-GPuA for ; Tue, 21 Oct 2014 22:09:45 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2112D1A8AAD for ; Tue, 21 Oct 2014 22:09:44 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "Gorman, Pierce A [NTK]" , "PFAUTZ, PENN L" , Brian Rosen Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA56YA//+9qJAACmPKAAAWprlc Date: Wed, 22 Oct 2014 05:09:42 +0000 References: <38726EDA2109264987B45E29E758C4D605741541@MISOUT7MSGUSRDD.ITServices.sbc.com> <, <>> <,<99353C47-A259-43F7-9723-681C0CFC97D8@brianrosen.net> <>> <,<818D18CE-7860-40CC-B342-F94F1B707EB0@brianrosen.net> <>> <38726EDA2109264987B45E29E758C4D605742230@MISOUT7MSGUSRDD.ITServices.sbc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/RDN5bQMhFHFrsmR0NLMadzcqQEk Cc: "modern@ietf.org" , Richard Shockey Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 05:09:48 -0000 If preventing SPIT relies on keeping a secret database of a rather limited = identifier space, I suspect we've lost the battle already...=0A= =0A= I'm not sure how read access would facilitate spam (or how restricting acce= ss would significantly interfere with automated sequential dialing).=0A= =0A= Maybe part of this is that we have not quite defined what elements would be= contained and accessible by whom - for example, "ownership" data might be = more tightly held (as is effectively the case in DNS today, with all the id= entity protection schemes that registrars and other offer). =0A= =0A= So far, we seem to have discussed, at least implicitly:=0A= =0A= * holder contact data (similar to the whois-style data for technical, admin= and billing contacts), possibly via indirection (SPID, OCN)=0A= * user data (who is being reached)=0A= * service indications, including pointers to protocol-based reachability in= formation (very roughly equivalent to NS records)=0A= =0A= Is there other data?=0A= =0A= ________________________________________=0A= From: Gorman, Pierce A [NTK] [Pierce.Gorman@sprint.com]=0A= Sent: Tuesday, October 21, 2014 10:13 AM=0A= To: PFAUTZ, PENN L; Brian Rosen; Henning Schulzrinne=0A= Cc: Richard Shockey; modern@ietf.org=0A= Subject: RE: [Modern] Services=0A= =0A= I am very leary of a public database. SPAM over Internet Telephony (SPIT) = is just as much a concern as it ever was.=0A= =0A= If the database is to be used by "carriers" of telecommunications services = (e.g., voice, 2-way video, presence capabilities, geo-location, emergency s= ervices call/text/etc), I would want the same restrictions to access as are= enjoyed by LERG and NPAC. I understand OTT providers may require access a= s well (I assume they will) but I would definitely not want it to be as ope= n as DNS.=0A= =0A= Best regards,=0A= =0A= =0A= Pierce Gorman=0A= Voice Architecture=0A= Core Planning/Sprint=0A= 913-439-4368 (Desk)=0A= =0A= =0A= -----Original Message-----=0A= From: PFAUTZ, PENN L [mailto:pp3129@att.com]=0A= Sent: October 21, 2014 8:16 AM=0A= To: Brian Rosen; Henning Schulzrinne=0A= Cc: Richard Shockey; Gorman, Pierce A [NTK]; modern@ietf.org=0A= Subject: RE: [Modern] Services=0A= =0A= I caught that too. How public would public be? I can imagine arguments for = some level of access control even if the database were on the Internet. And= I would want some protection from DDOS.=0A= =0A= -----Original Message-----=0A= From: Brian Rosen [mailto:br@brianrosen.net]=0A= Sent: Tuesday, October 21, 2014 9:14 AM=0A= To: Henning Schulzrinne=0A= Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.or= g=0A= Subject: Re: [Modern] Services=0A= =0A= It used to be that we did not want a public database of which service provi= der(s) served a specific telephone number. Is that now not an issue?=0A= =0A= Brian=0A= =0A= > On Oct 20, 2014, at 11:34 PM, Henning Schulzrinne wrote:=0A= >=0A= > I suspect we're trying to get at how many levels of indirection we allow = before we arrive at RFC 3263 and where, in one or more places, choices of s= ervice are expressed.=0A= >=0A= > Whether you designate a SPID or a domain name, there then has to be a sec= ond step to get something resolvable. Needless to say, you could use both, = since a SPID would presumably translate mechanically into a domain name lik= e 1234.neca.org=0A= >=0A= > Also, I'm confused by the model that people have in mind - we seem to sim= ultaneously be talking about information that is being returned by a public= number directory (before you know who is "in charge" of the number) and hi= ghly-customized information that differs based on who's asking.=0A= >=0A= > We need both, and they may well use the same wire protocol, but, if we ha= ve some kind of public numbering database, it can't tailor its response to = the querier, by definition.=0A= >=0A= > To make this a bit more concrete:=0A= >=0A= > (1) Query a public numbering database with the MODERN protocol, with inpu= t "number, service". Get a SPID or domain name, say modern.att.net.=0A= >=0A= > (2) Query domain name modern.att.net with MODERN, but with authentication= . Return customized SIP URL(s). [If the querier has no relationship to mode= rn.att.net, it would presumably get a generic answer for carriers without s= pecial arrangement or some version of "go away".]=0A= >=0A= > (3) Use RFC 3263 process for those URLs.=0A= >=0A= > Is that what people have in mind?=0A= >=0A= > ________________________________________=0A= > From: Brian Rosen [br@brianrosen.net]=0A= > Sent: Monday, October 20, 2014 10:11 AM=0A= > To: Henning Schulzrinne=0A= > Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf.= org=0A= > Subject: Re: [Modern] Services=0A= >=0A= > Okay, perhaps we are.=0A= >=0A= > I think "media" is not a good service, but we'll see. I think it's more = like voice/video/text/event. They can always all have the same response.= =0A= > I think that using SRV is not a good enough routing protocol, although al= lowing it would be fine with me. SRV, like lots of things, does not proper= ly consider the source, nor the location, both requirements.=0A= >=0A= > It might be okay to have a two step route where the first step resolves t= o a rendezvous for negotiation of the signaling and media interchange point= s, but I would think that would be the result of the first "modern" query = =3D it returns a URI where you negotiate interchange. The second step woul= d have some notion of location and source identity and returns route.=0A= >=0A= > Brian=0A= >=0A= >=0A= >> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne wrote:=0A= >>=0A= >> I suspect we're talking past each other. I'm not advocating a "golden ro= ot" or anything that looks like ENUM number-based mapping. As a strawman, c= onsider a JSON response within the MODERN context to a query for a phone nu= mber, returning for you=0A= >>=0A= >> "media": "myphone.brianrosen.net"=0A= >>=0A= >> with myphone.brianrosen.net=0A= >>=0A= >> resolving to=0A= >>=0A= >> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.=0A= >>=0A= >>=0A= >> I assume we don't want to put IP addresses directly into the response, s= o DNS enters the picture at some point.=0A= >>=0A= >> The alternative is to use the SRV or NAPTR service field (here, _sip._tc= p) directly in the MODERN response. I can see advantages to both.=0A= >>=0A= >> Henning=0A= >>=0A= >> ________________________________________=0A= >> From: Brian Rosen [br@brianrosen.net]=0A= >> Sent: Monday, October 20, 2014 9:51 AM=0A= >> To: Henning Schulzrinne=0A= >> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; modern@ietf= .org=0A= >> Subject: Re: [Modern] Services=0A= >>=0A= >> I really would like to get away from DNS entirely. We can reuse concept= s, but I think DNS is not the appropriate way to get anything to do with E.= 164s.=0A= >> ENUM was a mistake, and one of the mistakes was using DNS. It's not the= appropriate query mechanism, and it has a golden root problem. I remember= well the DNS guys questioning whether DNS was the right protocol when we s= tarted ENUM. We were so sure it was. It was a mistake then, and it is now= .=0A= >>=0A= >> Let's learn from that and stay away from DNS.=0A= >>=0A= >> We need a query with TN and service that returns either some form of ser= vice provider id/service URL and/or some form of route. I personally think= that it would be best to keep route separate from service provider id/URL = because I do think the user controls that part of the record while the SP c= ontrols the route.=0A= >>=0A= >> Brian=0A= >=0A= =0A= =0A= ________________________________=0A= =0A= This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.=0A= From nobody Fri Oct 24 10:44:37 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F201A1A8985 for ; Fri, 24 Oct 2014 10:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.333 X-Spam-Level: X-Spam-Status: No, score=0.333 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=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 mnSSoHKjLBA8 for ; Fri, 24 Oct 2014 10:44:34 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 DF2691A00E2 for ; Fri, 24 Oct 2014 10:44:34 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s9OHeXFh020729 for ; Fri, 24 Oct 2014 13:44:34 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1q776fhw5k-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 24 Oct 2014 13:44:34 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Fri, 24 Oct 2014 13:44:32 -0400 From: "McGarry, Tom" To: "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoA= Date: Fri, 24 Oct 2014 17:44:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.33.204.139] Content-Type: text/plain; charset="windows-1254" Content-ID: <557D8830A492C7439A3A09E9F03A2E18@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7600 signatures=670562 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410240147 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/tlK0hZuRMkhVrLXSOMzGCvwnDMU Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:44:37 -0000 Good about DNS: - Lightweight and fast - Widely deployed - Well understood technology - Well understood registration/administration model - Caching Problematic about DNS: - Vulnerable to attacks - Vulnerable to mining - Very little ability to expand functionality in the query and response - Can't reliably identify the originator of a query On 10/22/14 1:00 AM, "Henning Schulzrinne" wrote: > >Let's assume for a moment that organizations can directly get numbers, >e.g., a university or corporation. Why shouldn't they be able to >advertise their direct reachability and other characteristics, via (say) >SIP, just as they advertise their BGP or DNS reachability today? > >Whether to do that is obviously a policy decision, but I suspect it's >wise to plan for the ability of a large number of entities to acquire >numbers, whether that number is 100 million households, 6 million >businesses (with employees) or 6,000 (guestimate) of carriers and >kind-of-like-carriers entities. > >I suspect we mostly agree that there may not be a single master copy that >everybody accesses, but rather physically (and logically) distributed, >but synchronized, versions. > >Going back to the compatibility and learning from other public identifier >systems, what aspects of the DNS environment (not the protocol) are >important to clone and which have shown themselves to be problematic? > >________________________________________ >From: Modern [modern-bounces@ietf.org] on behalf of Gorman, Pierce A >[NTK] [Pierce.Gorman@sprint.com] >Sent: Tuesday, October 21, 2014 3:15 PM >To: Adam Roach; McGarry, Tom; modern@ietf.org >Subject: Re: [Modern] Services > >LERG and NPAC may fall into your categories of na=EFve, secret, requiring = a >special handshake, and right amount of money to access, but I would argue >with na=EFve. :-) > >Your concern is still valid and I agree. Slamming has been a problem in >the past even with controlled access. Perhaps database content of >services/SP associated with TN(s) associated with a typical consumer >subscriber can be controlled by the subscriber themselves? They do so >through the proxy of their telephone service carrier(s) today, but MODERN >technology (pun intended) might support a more direct role. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Adam Roach >Sent: October 21, 2014 1:07 PM >To: McGarry, Tom; modern@ietf.org >Subject: Re: [Modern] Services > >Hrm. I've heard OTT providers tossed around in this discussion as a >potential consumer of this data. It sounds like the last few messages >have been angling towards solutions that would provide high barriers to >entry to becoming such a provider. > >I'm thinking we should put some thought into how to deploy a system that >doesn't exclude small new players, while honoring the valid operational >concerns of incumbents. I'm very suspect of the naive approach of "well, >let's just make it a secret database that requires a special handshake >and/or the right amount of money to access." > >/a > >On 10/21/14 12:42, McGarry, Tom wrote: >> So there seems to be some pushback on a "public DB" and I tend to agree. >> This is why I've advocated that the administrator distributes these >> DBs to others, e.g., ISPs. Make them part of service providers' >> infrastructure with all the attendant security. The challenges here >> are around updating it and securing the data from the entity that is >> now hosting it. Securing primarily means making sure it can't be >> modified. But it could even mean protecting it from being mined. >> >> >> >> On 10/20/14 11:34 PM, "Henning Schulzrinne" >> >> wrote: >> >>> >>> I suspect we're trying to get at how many levels of indirection we >>> allow before we arrive at RFC 3263 and where, in one or more places, >>> choices of service are expressed. >>> >>> Whether you designate a SPID or a domain name, there then has to be a >>> second step to get something resolvable. Needless to say, you could >>> use both, since a SPID would presumably translate mechanically into a >>> domain name like 1234.neca.org >>> >>> Also, I'm confused by the model that people have in mind - we seem to >>> simultaneously be talking about information that is being returned by >>> a public number directory (before you know who is "in charge" of the >>> number) and highly-customized information that differs based on who's >>> asking. >>> >>> We need both, and they may well use the same wire protocol, but, if >>> we have some kind of public numbering database, it can't tailor its >>> response to the querier, by definition. >>> >>> To make this a bit more concrete: >>> >>> (1) Query a public numbering database with the MODERN protocol, with >>> input "number, service". Get a SPID or domain name, say modern.att.net. >>> >>> (2) Query domain name modern.att.net with MODERN, but with >>> authentication. Return customized SIP URL(s). [If the querier has no >>> relationship to modern.att.net, it would presumably get a generic >>> answer for carriers without special arrangement or some version of >>> "go away".] >>> >>> (3) Use RFC 3263 process for those URLs. >>> >>> Is that what people have in mind? >>> >>> ________________________________________ >>> From: Brian Rosen [br@brianrosen.net] >>> Sent: Monday, October 20, 2014 10:11 AM >>> To: Henning Schulzrinne >>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>> modern@ietf.org >>> Subject: Re: [Modern] Services >>> >>> Okay, perhaps we are. >>> >>> I think =B3media=B2 is not a good service, but we=B9ll see. I think it= =B9s >>> more like voice/video/text/event. They can always all have the same >>>response. >>> I think that using SRV is not a good enough routing protocol, >>> although allowing it would be fine with me. SRV, like lots of >>> things, does not properly consider the source, nor the location, both >>>requirements. >>> >>> It might be okay to have a two step route where the first step >>> resolves to a rendezvous for negotiation of the signaling and media >>> interchange points, but I would think that would be the result of the >>> first =B3modern=B2 query =3D it returns a URI where you negotiate >>> interchange. The second step would have some notion of location and >>> source identity and returns route. >>> >>> Brian >>> >>> >>>> On Oct 20, 2014, at 9:57 AM, Henning Schulzrinne >>>> wrote: >>>> >>>> I suspect we're talking past each other. I'm not advocating a >>>> "golden root" or anything that looks like ENUM number-based mapping. >>>> As a strawman, consider a JSON response within the MODERN context to >>>> a query for a phone number, returning for you >>>> >>>> "media": "myphone.brianrosen.net" >>>> >>>> with myphone.brianrosen.net >>>> >>>> resolving to >>>> >>>> _sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. >>>> >>>> >>>> I assume we don't want to put IP addresses directly into the >>>> response, so DNS enters the picture at some point. >>>> >>>> The alternative is to use the SRV or NAPTR service field (here, >>>> _sip._tcp) directly in the MODERN response. I can see advantages to >>>>both. >>>> >>>> Henning >>>> >>>> ________________________________________ >>>> From: Brian Rosen [br@brianrosen.net] >>>> Sent: Monday, October 20, 2014 9:51 AM >>>> To: Henning Schulzrinne >>>> Cc: Richard Shockey; PFAUTZ, PENN L; Gorman, Pierce A [NTK]; >>>> modern@ietf.org >>>> Subject: Re: [Modern] Services >>>> >>>> I really would like to get away from DNS entirely. We can reuse >>>> concepts, but I think DNS is not the appropriate way to get anything >>>> to do with E.164s. >>>> ENUM was a mistake, and one of the mistakes was using DNS. It=B9s not >>>> the appropriate query mechanism, and it has a golden root problem. >>>> I remember well the DNS guys questioning whether DNS was the right >>>> protocol when we started ENUM. We were so sure it was. It was a >>>> mistake then, and it is now. >>>> >>>> Let=B9s learn from that and stay away from DNS. >>>> >>>> We need a query with TN and service that returns either some form of >>>> service provider id/service URL and/or some form of route. I >>>> personally think that it would be best to keep route separate from >>>> service provider id/URL because I do think the user controls that >>>> part of the record while the SP controls the route. >>>> >>>> Brian >>> >>> _______________________________________________ >>> Modern mailing list >>> Modern@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai >>> lman_ >>> listinfo_modern&d=3DAAIF-g&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufv= eeID >>> cLext >>> Z1ooNcfp01IYIaVqsORjI&m=3Dp-GX438SeKr05SxFe3iI6PUOOwDZHgSQP90MfS5GNjU&s >>> =3D0X93 agRq2zPa5hhi0zXwAFwcRRgx7jgkNPJTCpuRWHc&e=3D >> _______________________________________________ >> Modern mailing list >> Modern@ietf.org >>=20 >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an >>_listinfo_modern&d=3DAAIFAw&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7Hufve= eIDcLe >>xtZ1ooNcfp01IYIaVqsORjI&m=3DFUoiui5whl_j5B36yZ2-2LUy9LlQiSlLfTsvnoz5j5U&s= =3Dp >>2IjM8qFlh4Kq6ZghEH4u0jj96fTG8NNeL5OOJzO0Rg&e=3D > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAAIFAw&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DFUoiui5whl_j5B36yZ2-2LUy9LlQiSlLfTsvnoz5j5U&s=3D= p2Ij >M8qFlh4Kq6ZghEH4u0jj96fTG8NNeL5OOJzO0Rg&e=3D > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_modern&d=3DAAIFAw&c=3DMOptNlVtIETeDALC_lULrw&r=3D4Klm32iB7HufveeI= DcLext >Z1ooNcfp01IYIaVqsORjI&m=3DFUoiui5whl_j5B36yZ2-2LUy9LlQiSlLfTsvnoz5j5U&s=3D= p2Ij >M8qFlh4Kq6ZghEH4u0jj96fTG8NNeL5OOJzO0Rg&e=3D=20 From nobody Mon Oct 27 15:02:59 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18131A00D7 for ; Mon, 27 Oct 2014 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Z-x9odGjHLJ7 for ; Mon, 27 Oct 2014 15:02:55 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id EE7D01A00C2 for ; Mon, 27 Oct 2014 15:02:54 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7Oopwzc68A///22zuAAReFAIAAECQAgAAaYXCAAFuixYABz8OAgAFPFfuAASLpAP//vUKegABIYoCAAJp0MoAA75wAgABKCwCAABMaAIAAXmGsgAP8KoCABP4I6w== Date: Mon, 27 Oct 2014 22:02:43 +0000 References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/modern/0pU_jKFZiwrTfvaEgCq0bzg9wa0 Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:02:57 -0000 I think the discussions have three facets:=0A= =0A= (1) DNS as an information retrieval protocol (which most of the bullets bel= ow seem to summarize succinctly);=0A= =0A= (2) domain names as a model for managing globally-unique identifiers, inclu= ding associating extensible lists of information (DNS records, in that case= ) with each name;=0A= =0A= (3) the protocols that are currently used to manage parts of (2), e.g., for= registrar-registry interactions and information retrieval about domain hol= ders.=0A= =0A= I think it would be helpful to clearly separate the three as we address req= uirements and choices.=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom [Tom.McGar= ry@neustar.biz]=0A= Sent: Friday, October 24, 2014 1:44 PM=0A= To: modern@ietf.org=0A= Subject: Re: [Modern] Services=0A= =0A= Good about DNS:=0A= - Lightweight and fast=0A= - Widely deployed=0A= - Well understood technology=0A= - Well understood registration/administration model=0A= - Caching=0A= =0A= Problematic about DNS:=0A= - Vulnerable to attacks=0A= - Vulnerable to mining=0A= - Very little ability to expand functionality in the query and response=0A= - Can't reliably identify the originator of a query=0A= =0A= =0A= From nobody Mon Oct 27 16:19:30 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5781A6FC6 for ; Mon, 27 Oct 2014 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.997 X-Spam-Level: * X-Spam-Status: No, score=1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 KyO8Mdh8iPrm for ; Mon, 27 Oct 2014 16:19:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F741A6FC5 for ; Mon, 27 Oct 2014 16:19:19 -0700 (PDT) Received: from BN1AFFO11FD015.protection.gbl (10.58.52.33) by BN1AFFO11HUB064.protection.gbl (10.58.52.215) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Mon, 27 Oct 2014 23:18:57 +0000 Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by BN1AFFO11FD015.mail.protection.outlook.com (10.58.52.75) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Mon, 27 Oct 2014 23:18:57 +0000 Received: from pdaasen2.corp.sprint.com (pdaasen2.corp.sprint.com [144.226.111.130]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9RNIurQ029062 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2014 18:18:56 -0500 Received: from PREWE13M01.ad.sprint.com (prewe13m01.corp.sprint.com [144.226.128.20]) by pdaasen2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9RNIt1D010061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Oct 2014 18:18:55 -0500 Received: from PLSWE13M01.ad.sprint.com (2002:90e5:d614::90e5:d614) by PREWE13M01.ad.sprint.com (2002:90e2:8014::90e2:8014) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 27 Oct 2014 19:18:54 -0400 Received: from PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9]) by PLSWE13M01.ad.sprint.com ([fe80::bd53:22c7:943c:2bb9%15]) with mapi id 15.00.0847.030; Mon, 27 Oct 2014 18:18:53 -0500 From: "Holmes, David W [CTO]" To: Henning Schulzrinne , "McGarry, Tom" , "modern@ietf.org" Thread-Topic: [Modern] Services Thread-Index: AQHP6XsgFax3o8mhdUeB6hFJJr7OopwzhHMAgAA62ICAANOHAIAAECQAgABedoCAAFw5AIABixeAgAGUfICAAN2CAIAAAc6AgAAD1oCAAOByAIAA7LGAgAAG+ACAABMaAIAAo2qAgAP6NACABP8hgP//uzgg Date: Mon, 27 Oct 2014 23:18:53 +0000 Message-ID: <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.229.32.56; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(13464003)(377454003)(199003)(50466002)(106466001)(80022003)(19580405001)(33646002)(106116001)(50986999)(46102003)(86362001)(19580395003)(44976005)(15975445006)(6806004)(21056001)(26826002)(120916001)(107046002)(85306004)(99396003)(23726002)(76482002)(108616004)(97756001)(2501002)(77096002)(107886001)(54356999)(76176999)(95666004)(46406003)(64706001)(92566001)(85852003)(87936001)(2656002)(47776003)(4396001)(20776003)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB064; H:pdaasdm1.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpda1.sprint.com; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB064; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0377802854 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.56 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.56; helo=pdaasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.56) smtp.mailfrom=David.Holmes@sprint.com; X-OriginatorOrg: sprint.com Archived-At: http://mailarchive.ietf.org/arch/msg/modern/txJkpCFFcEV4cZADOvQ9BWYEp14 Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:19:23 -0000 This is a great discussion & continues to follow the common IETF principles= of proposing a solution & then finding what patches it needs to meet some = implicit requirement(s). However, in this case, given the huge legacy coming in from both the IP & P= STN worlds, I suspect that perhaps we should consider modifying the process= somewhat, & first generate some kind of statement of requirements / proble= m statement. A large amount of the required information has already been a= ired, as we see below, so potentially this could be done without the expend= iture of much effort. Maybe what we need to start the process is an informational RFC that list o= ut all the identifiers in common use in this field, & how they are used, tr= anslated for routing, etc.? Based on that it should be easy to rationally = derive a set of requirements & (hopefully) figure which identifier(s) & sup= porting mechanisms can be minimally modified to produce a reasonable soluti= on. David Holmes Sprint -----Original Message----- From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning Schulzri= nne Sent: Monday, October 27, 2014 3:03 PM To: McGarry, Tom; modern@ietf.org Subject: Re: [Modern] Services I think the discussions have three facets: (1) DNS as an information retrieval protocol (which most of the bullets bel= ow seem to summarize succinctly); (2) domain names as a model for managing globally-unique identifiers, inclu= ding associating extensible lists of information (DNS records, in that case= ) with each name; (3) the protocols that are currently used to manage parts of (2), e.g., for= registrar-registry interactions and information retrieval about domain hol= ders. I think it would be helpful to clearly separate the three as we address req= uirements and choices. Henning ________________________________________ From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom [Tom.McGar= ry@neustar.biz] Sent: Friday, October 24, 2014 1:44 PM To: modern@ietf.org Subject: Re: [Modern] Services Good about DNS: - Lightweight and fast - Widely deployed - Well understood technology - Well understood registration/administration model - Caching Problematic about DNS: - Vulnerable to attacks - Vulnerable to mining - Very little ability to expand functionality in the query and response - Can't reliably identify the originator of a query _______________________________________________ Modern mailing list Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From nobody Mon Oct 27 20:29:15 2014 Return-Path: X-Original-To: modern@ietfa.amsl.com Delivered-To: modern@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5AB1A00FF for ; Mon, 27 Oct 2014 20:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.131 X-Spam-Level: **** X-Spam-Status: No, score=4.131 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FB_CIALIS_LEO3=3.899, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 IWDtYNyTsnoU for ; Mon, 27 Oct 2014 20:29:12 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 0537B1A1B01 for ; Mon, 27 Oct 2014 20:29:11 -0700 (PDT) Received: (qmail 24724 invoked by uid 0); 28 Oct 2014 03:29:07 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 28 Oct 2014 03:29:07 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 8ZUy1p0091MNPNq01ZV1mp; Tue, 28 Oct 2014 03:29:06 -0600 X-Authority-Analysis: v=2.1 cv=EP2VjTpC c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=xBIU4aAbsTwA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=_tdySTnJzJgA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=e5S2z_949zYtRReimy4A:9 a=g7dSsPt6NZ59JUv-:21 a=4seXG5V_ykI7xkMj:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 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=9dPLZp47LNwOpuG4je7cY+50m9CO3/bC4ibR0odZou0=; b=XPyTwnvYDOw6TIHLzjGR7Nbk7L/EKP1Kdj+A2ajax/vHr0u4+f2nlNCzO02xoLLJszz50lBWeVfJVkCxyT9K6BOSPi5uYAukgxtp4cJSnizMDOVJGrUlQGA8DwBfXKcL; Received: from [72.66.64.164] (port=49692 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XixSs-0008Sx-TJ; Mon, 27 Oct 2014 21:28:59 -0600 User-Agent: Microsoft-MacOutlook/14.4.5.141003 Date: Mon, 27 Oct 2014 23:28:53 -0400 From: Richard Shockey To: "Holmes, David W [CTO]" , Henning Schulzrinne , "McGarry, Tom" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] Services References: <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> In-Reply-To: <2347393ee1a94a5fa6bca2a21b8138d1@PLSWE13M01.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.64.164 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/modern/bZkPtQUlvIl7jKdVtKxegQ-SWmk Subject: Re: [Modern] Services X-BeenThere: modern@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers non-WG discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 03:29:14 -0000 There is still the first order problem of clearly and succinctly defining what is the problem statement. Everything else falls out from that. The value proposition would run something like this. How do we construct a set of tools that National Number Administrations can use to design systems for which E.164 identifiers can be properly and securely managed and authorized entities can create and use metadata associated with those E.164 identifiers to enable ubiquitous global communications.=20 David ..I can testify that other National Number Administrations are struggling with this. What is the history of the IETF with E.164 identifiers? Where has there been success and failure so far and why is new work needed. Certainly the history of ENUM is instructive. We all know what the successes and failures of that effort were and Tom McGarry correctly laid out the pros and cons of using DNS models. As you know Ive been there done that. I=B9ll volunteer to write that section. :-) We have looked at provisioning issues in DRINKS but that had its own issues associated with it and I, for one do not believe the existing DNS EPP tool kit RFC 4114 is an appropriate starting place for provisioning based on what we know of modern carrier systems. I=B9m not sure even the Domain Name Registration industry would go down the EPP route if they knew what they know now. It wouldn=B9t hurt to ask Scott Hollenbeck since he is the institutional memory of all of this. You correctly point out we somewhat trapped in legacy models and telephony provisioning systems are staggeringly expensive. I=B9ve argued that EPP is actually a IETF failure since it is not really a general purpose provisioning data exchange system it is highly bound to the domain name registry industry and as such carries a lot of baggage associated with it. Even HTTP/SOAP/XML has now been eclipsed for all sorts of reasons but it did work and was clearly more generic than other methods that proceeded it. We certainly know what people use in North America use SOA/LSMS interfaces for the NPAC and BIRDDS for the LERG etc and there is a lot of open documentation on all of those what the required fields are etc. We=B9d need to see every darn field currently in use and then see if it could have some mapping to some new system and certainly we have more modern Query Response mechanisms. Brian Rosen pointed out REST/JSON certainly comes to mind and I would certainly agree. There is the globalization problem. E.164 is a big name space but I reject the notion that the solution has to be globally applicable from day one. That is way too much of a stretch. Visions of global roots come into mind and my head wants to explode.=20 My basic suspicion is if we all sat down in a room for a day or two (with beer) a white board we could roughly outline the basics including one or more models of how registries would operate and I commend to your attention the work of IETF PAWS and the FCC White Spaces initiative on how a new federated registry model might actually work. Needless to say there is some level of Layer 9 here (politics) due to the nature of control of the namespace itself. This is telephony not the Internet. =8B=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 On 10/27/14, 7:18 PM, "Holmes, David W [CTO]" wrote: >This is a great discussion & continues to follow the common IETF >principles of proposing a solution & then finding what patches it needs >to meet some implicit requirement(s). > >However, in this case, given the huge legacy coming in from both the IP & >PSTN worlds, I suspect that perhaps we should consider modifying the >process somewhat, & first generate some kind of statement of requirements >/ problem statement. A large amount of the required information has >already been aired, as we see below, so potentially this could be done >without the expenditure of much effort. > >Maybe what we need to start the process is an informational RFC that list >out all the identifiers in common use in this field, & how they are used, >translated for routing, etc.? Based on that it should be easy to >rationally derive a set of requirements & (hopefully) figure which >identifier(s) & supporting mechanisms can be minimally modified to >produce a reasonable solution. > >David Holmes >Sprint > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Henning >Schulzrinne >Sent: Monday, October 27, 2014 3:03 PM >To: McGarry, Tom; modern@ietf.org >Subject: Re: [Modern] Services > >I think the discussions have three facets: > >(1) DNS as an information retrieval protocol (which most of the bullets >below seem to summarize succinctly); > >(2) domain names as a model for managing globally-unique identifiers, >including associating extensible lists of information (DNS records, in >that case) with each name; > >(3) the protocols that are currently used to manage parts of (2), e.g., >for registrar-registry interactions and information retrieval about >domain holders. > >I think it would be helpful to clearly separate the three as we address >requirements and choices. > >Henning > >________________________________________ >From: Modern [modern-bounces@ietf.org] on behalf of McGarry, Tom >[Tom.McGarry@neustar.biz] >Sent: Friday, October 24, 2014 1:44 PM >To: modern@ietf.org >Subject: Re: [Modern] Services > >Good about DNS: >- Lightweight and fast >- Widely deployed >- Well understood technology >- Well understood registration/administration model >- Caching > >Problematic about DNS: >- Vulnerable to attacks >- Vulnerable to mining >- Very little ability to expand functionality in the query and response >- Can't reliably identify the originator of a query > > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern