Re: [dispatch] VIPR - proposed charter version 3

Peter Musgrave <peter.musgrave@magorcorp.com> Tue, 06 July 2010 15:32 UTC

Return-Path: <peter.musgrave@magorcorp.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 2052F3A680D; Tue, 6 Jul 2010 08:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.552
X-Spam-Level:
X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 ChZG75nMGhcr; Tue, 6 Jul 2010 08:32:12 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D84283A65A6; Tue, 6 Jul 2010 08:32:11 -0700 (PDT)
Received: by gxk3 with SMTP id 3so1487013gxk.31 for <multiple recipients>; Tue, 06 Jul 2010 08:32:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.226.208 with SMTP id ix16mr2765641qcb.175.1278428452981; Tue, 06 Jul 2010 08:00:52 -0700 (PDT)
Received: by 10.229.220.10 with HTTP; Tue, 6 Jul 2010 08:00:52 -0700 (PDT)
In-Reply-To: <4C333D8E.6090505@nostrum.com>
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> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> <AANLkTimfo4UVcjS9N2Es01_GOZnWcYH7Bc2iRmPRQTXZ@mail.gmail.com> <4C333D8E.6090505@nostrum.com>
Date: Tue, 06 Jul 2010 11:00:52 -0400
Message-ID: <AANLkTilIbT7hNvCwPeXxOoaQb2kD0x95o5LiPBry8e-D@mail.gmail.com>
Subject: Re: [dispatch] VIPR - proposed charter version 3
From: Peter Musgrave <peter.musgrave@magorcorp.com>
To: Adam Roach <adam@nostrum.com>, Cullen Jennings <fluffy@cisco.com>, jonathan@rosen.net
Content-Type: multipart/alternative; boundary="001636310151cf8dff048ab95178"
X-Mailman-Approved-At: Wed, 07 Jul 2010 09:53:09 -0700
Cc: DISPATCH <dispatch@ietf.org>, IETF-Discussion list <ietf@ietf.org>, Richard Shockey <richard@shockey.us>
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 15:32:13 -0000

Yeah. Sigh.

I guess the issue then becomes whether this is enough of a step in right
direction that it can be built on - and whether it's worth the effort.

Cullen/Jonathan - can you speak to any of the operational issues w.r.t.
'failure surprise' in the existing implementation?

Regards,

Peter Musgrave

On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach <adam@nostrum.com> wrote:

>  On 7/6/10 7:20 AM, Peter Musgrave wrote:
>
>> From my perspective what this is really about is the ability for me to
>> have interoperable ad-hoc video calls between businesses which can be
>> established via SIP with a "good enough" level of authentication and
>> security.
>>
>
>
> You're looking in the wrong place, then.
>
> The problem is that VIPR really provides something more like "random
> failure surprise," as some portion of the call attempts must go over the
> (non-video-capable) PSTN. The user doesn't have any idea about, or control
> over, when this will happen. So while it might be something you could use
> for personal purposes -- where frequent video call setup failures would be
> okay -- I doubt it's a viable video solution in a business environment. To
> run a business, you need something better than "random failure surprise".
>
> /a
>