Re: [dispatch] VIPR - proposed charter version 2

Cullen Jennings <fluffy@cisco.com> Thu, 17 June 2010 20:02 UTC

Return-Path: <fluffy@cisco.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 492B63A69EC for <dispatch@core3.amsl.com>; Thu, 17 Jun 2010 13:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.359
X-Spam-Level:
X-Spam-Status: No, score=-109.359 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 hIcRsqViiUlR for <dispatch@core3.amsl.com>; Thu, 17 Jun 2010 13:02:43 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 72D123A6B15 for <dispatch@ietf.org>; Thu, 17 Jun 2010 13:02:43 -0700 (PDT)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkoFAI4cGkyrR7H+/2dsb2JhbACeI1dxp26aOYJZgkEEg1I
X-IronPort-AV: E=Sophos;i="4.53,433,1272844800"; d="scan'208";a="226951283"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2010 20:02:36 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5HK2YNp010592; Thu, 17 Jun 2010 20:02:35 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <A444A0F8084434499206E78C106220CAE6057737@MCHP058A.global-ad.net>
Date: Thu, 17 Jun 2010 14:02:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <36131FA9-BE57-4B01-A6CC-8467BF239C40@cisco.com>
References: <DB6CA94F-0EC9-4E27-A190-D12029CA61AE@cisco.com> <A444A0F8084434499206E78C106220CAE6057737@MCHP058A.global-ad.net>
To: John Elwell <john.elwell@siemens-enterprise.com>, Dale Worley <dworley@nortel.com>
X-Mailer: Apple Mail (2.1078)
Cc: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] VIPR - proposed charter version 2
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: Thu, 17 Jun 2010 20:02:45 -0000

In general I think we should make charters  as specific as possible  but still broad enough to encompass the various types of solutions we want to consider for the problem. I think that helps things get done sooner. 

So if someone had a proposal on the table to solve this in some non peer to peer way, it would be easier to decide if we should do it in the same WG or something different. But we been talking about ideas for this for 6 months now and no one has put together a proposal for some non peer to peer approach. I've heard lots of proposal to variations of the basic vipr scheme but they all leverages to peer to peer approach. I don't want a charter that is so vague that it is a research project. If someone has a specific approach that they think we should consider, then I'd certainly want to talk about that and adjust the proposed charter accordingly but, lacking that, I prefer a charter that makes it pretty clear what the WG is going to go do and not an exploratory type charter. 

As far as solving the problem with a centralized database, I think the DRINKS/SPEERMINT folks are pretty much doing the standardization works that would be needed for that approach. For the places that will work, it's an easier approach than VIPR which is looking for an approach for the places that does not make business sense. 

Cullen

PS - I know what you mean by peer to peer here but don't even get me going about the difficulties of trying to define if something is peer to peer or not :-) 


On Jun 17, 2010, at 10:24 AM, Elwell, John wrote:

> "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..."
> Does it necessarily have to be a peer-to-peer based approach? The ENUM/DNS approach is still a good approach for querying, but the issue is that with public ENUM the database simply doesn't get populated. So the key issue is finding a secure and attractive way of populating the database. Does the charter really need to include the words "peer to peer based", or should that be left as a matter for discussion at the solution stage?
> 
> John
> 
> 
> > -----Original Message-----
> > From: dispatch-bounces@ietf.org
> > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings
> > Sent: 15 June 2010 18:25
> > To: DISPATCH list
> > Subject: [dispatch] VIPR - proposed charter version 2
> >
> >
> > Thanks for all the comments on the list. Here is a revised version:
> >
> > (PS. If anyone else wants to edit, this is in SVN and glad to
> > get anyone write permission)
> >
> > ========================================
> >
> > ViPR Charter Proposal (Version 2)
> >
> > WG Name:  Verification Involving PSTN Reachability (VIPR)
> >
> > 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 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. In
> > this context, we use "responsible" to mean an administrative domain
> > would would be at least one of the administrative domains that a PSTN
> > call to this phone number would be routed to. Once the domain
> > responsible for the phone number is found, existing protocols such as
> > SIP and XMPP can be used for inter-domain communications.
> >
> > Some validation protocols may be based on knowledge gathered around a
> > SIP 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. The WG will select and standardize at least one
> > validation scheme.
> >
> > To help mitigate SPAM issues when using SIP between domains,
> > the WG will
> > define a mechanisms to enable one domain to check that incoming SIP
> > messages from a different domain are coming from a domain that
> > successfully validated a phone number. The working group will
> > define new
> > SIP headers and option tags 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 problem statement and some possible starting points for solutions
> > are further discussed in the following internet drafts which
> > shall form
> > the bases of the WG documents:
> >
> > draft-rosenberg-dispatch-vipr-overview
> > draft-rosenberg-dispatch-vipr-reload-usage
> > draft-rosenberg-dispatch-vipr-pvp
> > draft-rosenberg-dispatch-vipr-sip-antispam
> >
> > The working group will carefully coordinate with the security
> > area, O&M
> > area, as well as the appropriate RAI WG including sipcore and p2psip.
> >
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html