Re: [dispatch] VIPR - proposed charter version 2 - PSTN?

Peter Musgrave <peter.musgrave@magorcorp.com> Wed, 16 June 2010 11:53 UTC

Return-Path: <peter.musgrave@magorcorp.com>
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 781923A6B2F for <dispatch@core3.amsl.com>; Wed, 16 Jun 2010 04:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.29
X-Spam-Level:
X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
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 OyvVmqOcbetX for <dispatch@core3.amsl.com>; Wed, 16 Jun 2010 04:53:15 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8C8863A689C for <dispatch@ietf.org>; Wed, 16 Jun 2010 04:53:15 -0700 (PDT)
Received: by qwe5 with SMTP id 5so6449qwe.31 for <dispatch@ietf.org>; Wed, 16 Jun 2010 04:53:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.96.15 with SMTP id f15mr4225848qan.67.1276689197154; Wed, 16 Jun 2010 04:53:17 -0700 (PDT)
Received: by 10.229.217.16 with HTTP; Wed, 16 Jun 2010 04:53:16 -0700 (PDT)
In-Reply-To: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com>
References: <DB6CA94F-0EC9-4E27-A190-D12029CA61AE@cisco.com> <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com>
Date: Wed, 16 Jun 2010 07:53:16 -0400
Message-ID: <AANLkTilC-Qcndd6HfaRpDA_HYG-G3Dw_upkwxsIc-9TH@mail.gmail.com>
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: Roni Even <Even.roni@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN?
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, 16 Jun 2010 11:53:16 -0000

Hi,

I think the use of PSTN reachability is central to ViPR and it's
value. I agree there will be other ways of authenticating and that
over time they may displace ViPR but I think PSTN reachability will be
around for a long time. I think it is the lowest-common denominator
and avoids things like trying to interface to databases of PSTN
numbers and all the assorted standards and security issues that
entails.

I see this as a temporary solution in the same way that NAT traversal
is a temporary solution :-)

Perhaps we should make it clear in the charter that the work requires
that a node using ViPR have the ability to make and receive PSTN calls
(or interface to something that does)?

I think general authentication without using PSTN reachability is a
great idea - but I think that is a far larger and more complex issue.
IIUC ViPR exists to circumvent that issue and provide a shorter term,
standards-based, pragmatic solution. I think the more general problem
would need a charter unto itself.

Peter Musgrave

On Wed, Jun 16, 2010 at 2:22 AM, Roni Even <Even.roni@huawei.com> wrote:
> Hi,
> I read the charter and the listed drafts. I have no problem with the first
> two paragraph of the charter
>
> "There are two globally deployed address spaces for communications that more
> than a billion people use on a daily basis. They are 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. The goal of this working group is to enable inter-domains
> communications over the internet, using protocol such as SIP, while still
> allowing people to use phone numbers to identify the person they wish to
> communicate with.
>
> The VIPR WG will address this problem by developing a peer to peer based
> approach to finding domains that claim to be responsible for a given phone
> number and validation protocols to ensure a reasonable likelihood that a
> given domain actually is responsible for the phone number."
>
> I have a concern about using PSTN infrastructure for the reachability. My
> understanding so far was that SIP is trying to provide a new way for end to
> end communication that will replace the existing circuit switch
> infrastructure. This proposal says that the way to achieve end to end
> connectivity requires to have an end to end PSTN frastructure.
>
> The third paragraph is talking about validation using PSTN calls. I think
> that we can look at validation of number ownership but should say that
> requiring PSTN calls to do it is not the recommended approach. This will
> allow managing of PSTN numbers not in the scope of PSTN infrastructure. Even
> the PSTN network is using external protocol like SS7 to route calls using
> databases for achieving reachability so why not say we can use similar
> infrastructure that will be IP based.
>
> I can understand this as a temporary solution but not as a standard
> developed by the IETF.
>
>
>  Thanks
>
> Roni Even
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>