Re: [dispatch] VIPR Charter

"Richard Shockey" <richard@shockey.us> Wed, 12 January 2011 15:06 UTC

Return-Path: <richard@shockey.us>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC1028C11C for <dispatch@core3.amsl.com>; Wed, 12 Jan 2011 07:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.892
X-Spam-Level:
X-Spam-Status: No, score=-101.892 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 R8nWuxE+GrVR for <dispatch@core3.amsl.com>; Wed, 12 Jan 2011 07:06:51 -0800 (PST)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id DD48C28C107 for <dispatch@ietf.org>; Wed, 12 Jan 2011 07:06:50 -0800 (PST)
Received: (qmail 27062 invoked by uid 0); 12 Jan 2011 15:09:10 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 12 Jan 2011 15:09:10 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To: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=SnN3w3/PlAU4EtE2MWTXiuE9a9Fj8+WqS6ZulWy51jytDIdL//EWKMKyWk5exNMxKWSlKRqp27CRK7NRotllP7MkzbpITB9AJlzUGInnM6hP/81MBR1MVNYsG+7lbcte;
Received: from pool-173-79-200-247.washdc.fios.verizon.net ([173.79.200.247] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1Pd2Jx-000652-RF; Wed, 12 Jan 2011 08:09:10 -0700
From: Richard Shockey <richard@shockey.us>
To: 'Marc Petit-Huguenin' <petithug@acm.org>, dispatch@ietf.org
References: <4D2B85D9.8010003@acm.org>
In-Reply-To: <4D2B85D9.8010003@acm.org>
Date: Wed, 12 Jan 2011 10:09:07 -0500
Message-ID: <008c01cbb26a$a96f9210$fc4eb630$@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: AcuxFHfxR0N4/o9kRmiotgSQ0gjTQgBVEabQ
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.200.247 authed with richard@shockey.us}
Subject: Re: [dispatch] VIPR Charter
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jan 2011 15:06:52 -0000

I still don't see how you can write a charter without dealing with the
Number Portability issue. You really need to be explicit that this proposed
methodology WILL FAIL in cases where the PSTN authority for the phone number
changes. It just needs to be called out.

Plus I really take issue with the case that private federations don't scale.
There is no evidence of that at all. IN addition its really irrelevant to
discuss why ENUM in e164.apra did not deploy. Needless to say when you do
have the cooperation of governmental or service provider administrative
entities within an jurisdiction it can and does work well. 

I certainly don't have any real issue with this work going forward. I'm a
great fan of letting folks actually do things they want to so long as it is
explicit what the limitations are. I'm sure there are folks that can and
would use this technique. I only wish those who continue to oppose the
extensions of ENUM for E2MD for instance would be as charitable. 

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Marc Petit-Huguenin
Sent: Monday, January 10, 2011 5:19 PM
To: dispatch@ietf.org
Subject: [dispatch] VIPR Charter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On the advice of the DISPATCH chairs, I am reposting below the latest
version of
the VIPR charter for additional feedback.

They are not considered as candidates for WG documents under this charter,
but
FYI the ViPR drafts were last updated in October 2010, and will probably be
updated again before Prague:

http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-0
4.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload-usa
ge-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-antisp
am-03.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03.txt

Thanks.

- ------------------------------------------------------------------------

VIPR Charter Proposal (Version 4)

WG Name:  Verification Involving PSTN Reachability (VIPR)

There are two globally deployed address spaces for communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users, thus DNS lookups are not sufficient. Other approaches
such as public ENUM are not sufficient due to lack of widespread
deployment for non-technical reasons - i.e., the involvement of
government and service provider administrative entities needing to
approve and populate the registries.  Private federations have been
established to workaround the issue, however, that solution is not
scalable. The goal of this working group is to enable inter-domain
communications over the the Internet, using protocols such as SIP,
while still allowing people to use phone numbers to identify the person
with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. Validation protocols will be developed to ensure a
reasonable likelihood that a given domain actually is responsible for
the phone number. In this context, "responsible" means an
administrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed. Once the domain
responsible for the phone number is found, existing protocols, such
as SIP, can be used for inter-domain communications.

Some validation protocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received over
the PSTN based on start and stop times. Other validation schemes, such
as examining fingerprints or watermarking of PSTN media to show that a
domain received a particular PSTN phone call, may also be considered by
the working group. This validation will be accomplished using publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate.  The WG will select and
standardize at least one validation scheme.

The validation mechanism requires a domain to gather and maintain
information related to PSTN calls.  This information is used by call
agents such as phones, SBCs and IP PBXs to route calls.  The WG will
define a client-server protocol between these call agents and the entity
within a domain that maintains the information.

To help mitigate SPAM issues when using SIP between domains, the WG will
define a mechanism to enable one domain to check that incoming SIP
messages are coming from a validated phone number.  A phone number is
considered validated if it is coming from a domain to which the calling
domain had previously successfully placed a PSTN call.  The working
group will define new SIP headers and option tags, as necessary, to
enable this.

The essential characteristic of VIPR is establishing authentication by
PSTN reachability when it is not possible to use a direct reference to
ENUM databases or other direct assertions of PSTN number
ownership. Elements such as public ENUM easily coexist with VIPR but no
direct interaction with ENUM will be required.  The solution set defined
by this WG will be incrementally deployable using only existing
interfaces to the PSTN.  No changes will be required to existing PSTN
capabilities, no new database access is needed nor is any new support
from PSTN service providers required.

The WG will produce the following deliverables:

1) A document describing the requirements, problem statement and
architectural approach to support SIP inter-domain communications.
2) A document describing the use of the p2psip protocol (RELOAD) as
applied to this problem space.
3) A document defining a scheme for validating the phone numbers using
publicly available open interfaces to the PSTN.
4) A document defining client-server protocol between call agents and the
entity within a domain that gathers and maintains information related to
PSTN calls.
5) A document describing a mechanism to mitigate SPAM issues.

The working group will carefully coordinate with the security area, O&M
area, as well as the appropriate RAI WGs such as sipcore and p2psip.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0rhdIACgkQ9RoMZyVa61c3rACeIZEoXE5f7+JlqL15Pg2ABeBP
ImAAmQHK60c9Tcf6/tME+fSbWJRZOSe6
=Spko
-----END PGP SIGNATURE-----
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch