Re: [dispatch] VIPR - proposed charter version 3

Paul Kyzivat <pkyzivat@cisco.com> Tue, 06 July 2010 17:23 UTC

Return-Path: <pkyzivat@cisco.com>
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 7B12A3A6980; Tue, 6 Jul 2010 10:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 3YlPIzDSEqcr; Tue, 6 Jul 2010 10:23:58 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5269A3A6944; Tue, 6 Jul 2010 10:23:58 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFMDM0xAZnwN/2dsb2JhbACgAnGnP5pNhSUEiDo
X-IronPort-AV: E=Sophos;i="4.53,547,1272844800"; d="scan'208";a="129313803"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2010 17:24:00 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66HO09Y028662; Tue, 6 Jul 2010 17:24:00 GMT
Message-ID: <4C3366B0.8080005@cisco.com>
Date: Tue, 06 Jul 2010 13:24:00 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Richard Shockey <richard@shockey.us>
Subject: Re: [dispatch] VIPR - proposed charter version 3
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>
In-Reply-To: <008d01cb1c72$9bdb96a0$d392c3e0$@us>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Jul 2010 09:53:09 -0700
Cc: 'DISPATCH' <dispatch@ietf.org>, 'IETF-Discussion list' <ietf@ietf.org>, 'Peter Musgrave' <peter.musgrave@magorcorp.com>
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 17:23:59 -0000

Richard Shockey wrote:
> Paul of course I've read them, though the PVP document is uniquely dense and
> gave me a headache. Security by ID Obscurity. 
> 
> My assertion still stands. In the absence of any linkage in the PVP to the
> E164 numbering authorities and or databases any assertion about verification
> and validation of a E.164 is in essence self validation. The charter does
> NOT state that. My point is the proposed charter is badly written and
> implies a trust model that does not exist.
> 
> You make a phone call if it answers and you hopefully get a caller ID that
> hasn't been spoofed then maybe you are OK and maybe you hope the TTL is set
> to some interval that doesn't cause number hijacking. But gee what happens
> when the number is disconnected from the PSTN? Hummmm
> 
> The use of the term validation and or verification here implies
> authentication and 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.  Consequently the charter implies an ability to develop a
> solution which we all know is impossible. 

Perhaps better terms can be found and used.

But the end effect is that the destination you reach using ViPR has the 
same assuredness of being who you thought it would be as an actual PSTN 
call has.

For the most part, that is a level of assurance that many people are 
comfortable with, even if we know that is not as reliable as most people 
think it is. And regardless of whether it is as good as people would 
like, it is as good as can be had in most cases with the current state 
of the art.

	Thanks,
	Paul