Re: [dispatch] VIPR - proposed charter version 3

Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 28 June 2010 18:00 UTC

Return-Path: <mary.ietf.barnes@gmail.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 41B2B3A6916 for <dispatch@core3.amsl.com>; Mon, 28 Jun 2010 11:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.36
X-Spam-Level:
X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_20=-0.74]
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 kuxSup0quhY5 for <dispatch@core3.amsl.com>; Mon, 28 Jun 2010 11:00:00 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C0E6E3A67B1 for <dispatch@ietf.org>; Mon, 28 Jun 2010 10:59:59 -0700 (PDT)
Received: by ewy22 with SMTP id 22so284189ewy.31 for <dispatch@ietf.org>; Mon, 28 Jun 2010 11:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9amVmEbVAzrR7m8E1tIzHdmDNWCbRpE8ooaPArXXMX0=; b=fnbgMM4hfY3jWYAjbdR9iLXeP6JlSRw3R8THEesTuYskZbLNHJyoW/9E/GBWT4cE5B vpIhus853cnvlZ9VZmCncSOlwnxroLG8kgDGVxQWSY6naVJ4of7sbXThmFKQmvqua2Qj TxZ4aJ6UkWL5BYwcV6GcqRoZOADTbGTc7wL80=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Tu1tCNn2jVautZFeXp7hEwrZVjaZauoQV40bk4OOBHPXlIolbme0+kWAD7FJIGNqwh ToJRZyYoJpjgso1wJgQno+aMDcHL774aOxdvfFvWRpelm7rdGc5WN/m1eJ4tfBZs/Amo e/gNaFMO6kn7JV778qziE8iUxLS+rSsvHMZJY=
MIME-Version: 1.0
Received: by 10.213.20.132 with SMTP id f4mr1897884ebb.33.1277748006430; Mon, 28 Jun 2010 11:00:06 -0700 (PDT)
Received: by 10.231.146.206 with HTTP; Mon, 28 Jun 2010 11:00:06 -0700 (PDT)
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE213F8C43A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com> <EDC0A1AE77C57744B664A310A0B23AE213F8C43A@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Date: Mon, 28 Jun 2010 13:00:06 -0500
Message-ID: <AANLkTiknOb92nDGrm9sjD5LLh9mvkVqSS75SrzyGrniX@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] VIPR - proposed charter version 3
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: Mon, 28 Jun 2010 18:00:01 -0000

Hi Keith,

That's a valid concern and we can rewrite the deliverables as
functional descriptions as we have done for other WG charters even in
cases where documents existed (e.g., overload).  The current text is
trying to say that these documents map to deliverables and can be used
as WG documents, although as it notes these should be considered
starting points (i.e., it's understood the proposed WG has change
control), but certainly the current text is somewhat misleading.

Thanks,
Mary.

On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith)
<keith.drage@alcatel-lucent.com> wrote:
> I have a major issue with including "which shall form the bases of the WG documents" into the charter. To me this is confusing the charter discussion with the working group that might eventually result deciding what its deliverables, and their contents, shall be.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
>> Sent: Monday, June 28, 2010 6:38 PM
>> To: DISPATCH
>> Subject: [dispatch] VIPR - proposed charter version 3
>>
>> Hi all,
>>
>> Below, please find version 3 of the VIPR proposed charter.
>> It's been updated to reflect ML feedback, in particular VAP
>> has been added and clarifications have been made with regards
>> to impacts (i.e., none) on existing PSTN interfaces.
>>
>> Regards,
>> Mary
>> (DISPATCH WG co-chair)
>>
>> ============================================
>> VIPR Charter Proposal (Version 3)
>>
>> 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. 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 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, "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 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
>> draft-rosenberg-dispatch-vipr-vap
>>
>> 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.
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>