RE: [dispatch] VIPR - proposed charter version 3
"Richard Shockey" <richard@shockey.us> Tue, 06 July 2010 01:27 UTC
Return-Path: <richard@shockey.us>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827E63A691D for <ietf@core3.amsl.com>; Mon, 5 Jul 2010 18:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.01
X-Spam-Level:
X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2JR6atkKfiu for <ietf@core3.amsl.com>; Mon, 5 Jul 2010 18:27:02 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 6A3C33A67B7 for <ietf@ietf.org>; Mon, 5 Jul 2010 18:27:02 -0700 (PDT)
Received: (qmail 26776 invoked by uid 0); 6 Jul 2010 01:27:04 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 6 Jul 2010 01:27:03 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=h7zDKkUEIvdTvouXTa1KCjQ/L0rqbcD1be7kEshe5j/sMMlZgKSc8Mnc7HqUscCNVfWLzvqkRcGGZyTA1bP2hiBGE8FK/CUoLnSdeO/gZNLjOM1rWGFjMgU38G+NSpc7;
Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1OVwwB-0007ZJ-Kk; Mon, 05 Jul 2010 19:27:03 -0600
From: Richard Shockey <richard@shockey.us>
To: 'Lawrence Conroy' <lconroy@insensate.co.uk>
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F40FB@307622ANEX5.global.avaya.com> <AANLkTinCs4ooaP7qczjOf_CMJB2tZg9XR9Ro5H-WWHK6@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F4219@307622ANEX5.global.avaya.com> <001201cb1ade$4195f680$c4c1e380$@us> <AANLkTimGO9mf_q78EYJJ_UwuM834m3vJ0i4BiGqEB4KJ@mail.gmail.com> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk>
In-Reply-To: <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk>
Subject: RE: [dispatch] VIPR - proposed charter version 3
Date: Mon, 05 Jul 2010 21:27:01 -0400
Message-ID: <01f801cb1caa$5667eaa0$0337bfe0$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcscnCkWhjKI35+fQNiG3Tjx6egbNAADFVqg
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us}
Cc: 'Paul Kyzivat' <pkyzivat@cisco.com>, 'DISPATCH' <dispatch@ietf.org>, 'IETF-Discussion list' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 01:27:03 -0000
Thank you Brother Conroy... this is a full IETF discussion since it does involve the creation of a new working group that does not seem to understand what is actually involved in E.164 validation. I do understand what this is really about..how do we screw global voice service providers since the IETF has not been able to convince normal folk to use SIP URI's. A reasonable objective, but I haven't seen many SIP URI on the back of plumbing or tree conservation trucks driving down my Reston VA neighborhoods recently. HTTP URI's are another thing. The real ultimate question is, can we, the SIP community, possibly learn to live with E.164 in SIP in some rational manner? Phone numbers are not going to go away as much as my dear friend Henry Sinnreich would prefer. -----Original Message----- From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] Sent: Monday, July 05, 2010 7:46 PM To: Richard Shockey Cc: Paul Kyzivat; DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, folks, [removing ietf-general as cross-posting this whole thread doesn't help, IMHO] I have remained silent so far, but just to clarify... Richard is absolutely correct. The comments on ENUM seemed to miss WHY public ENUM has been hard to roll out. Each country (or region) has its own idea of Eligibility criteria for ENUM domain registration in its jurisdiction. One thing they pretty much every one of the authorities agrees on is that *AT LEAST* there has to be a demonstrable proof that the domain owner is provided (or provides) service via the associated E.164 number. To say that this is a challenge to arrange cheaply or simply (or at all) is an understatement. Trust me; I know to my cost, as does Richard. Even that does not demonstrate that a value published in an ENUM domain MUST be, by some guarantee, always tied to that domain and its associated E.164 number. If I own a domain, I can provision what I like in that domain. The validation "hook" is tied some way to the numbering authority for E.164 numbers in a particular jurisdiction, and there IS no validation authority that ties a SIP URI to an E.164 number. In private ENUM clouds, carriers "know their own" and trust partner carriers (at least partially). That's a set of contractual agreements, nothing more. The real question you have to ask is: can you gain access to the basic information on which the private ENUM domains provisioning is based? If you are part of that federation, then yes (at least you can query the private ENUM tree). If you are outside that federation, then no protocol magic is going to change that fact. Sorry for the long post, but it isn't a protocol issue; that well be LDAP (or something that scales). It's an operational and contractual agreement between CSPs, and last I heard that was not an IETF topic. all the best, Lawrence On 5 Jul 2010, at 19:48, Richard Shockey wrote: > my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service provider > or national numbering authority is not possible under the current regulatory > circumstances.
- RE: [dispatch] VIPR - proposed charter version 3 Romascanu, Dan (Dan)
- RE: [dispatch] VIPR - proposed charter version 3 Romascanu, Dan (Dan)
- RE: [dispatch] VIPR - proposed charter version 3 Romascanu, Dan (Dan)
- RE: [dispatch] VIPR - proposed charter version 3 Roni Even
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Marc Petit-Huguenin
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Adam Roach
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Paul Kyzivat
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Adam Roach
- RE: [dispatch] VIPR - Speaking of Video Calls .. Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Paul Kyzivat
- Re: [dispatch] VIPR - proposed charter version 3 Cullen Jennings
- RE: [dispatch] VIPR - proposed charter version 3 Dan Wing
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Jonathan Rosenberg