IETF Logo Mail Archive

Re: [dispatch] (VIPR) - VAP in or out?

Marc Petit-Huguenin <petithug@acm.org> Tue, 15 June 2010 22:28 UTC

Return-Path: <petithug@acm.org>
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 6223F3A68DF for <dispatch@core3.amsl.com>; Tue, 15 Jun 2010 15:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.019
X-Spam-Level:
X-Spam-Status: No, score=-99.019 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_50=0.001, 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 7bJnE631tX5H for <dispatch@core3.amsl.com>; Tue, 15 Jun 2010 15:28:41 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 54A5F3A69A0 for <dispatch@ietf.org>; Tue, 15 Jun 2010 15:28:41 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id B28626C98478; Tue, 15 Jun 2010 22:28:45 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3AB006C98472; Tue, 15 Jun 2010 22:28:45 +0000 (UTC)
Message-ID: <4C17FE9C.9070902@acm.org>
Date: Tue, 15 Jun 2010 15:28:44 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Iceowl/1.0b1 Icedove/3.0.4
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <D92721E4-36AC-4B75-BCDF-E90A9242A286@cisco.com> <4C06A36B.3090103@acm.org> <E3FD94DC-61AA-411A-A4EF-5303C1D1DD97@cisco.com>
In-Reply-To: <E3FD94DC-61AA-411A-A4EF-5303C1D1DD97@cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] (VIPR) - VAP in or out?
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: Tue, 15 Jun 2010 22:28:42 -0000

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

On 06/15/2010 10:23 AM, Cullen Jennings wrote:
> 
> On Jun 2, 2010, at 12:31 PM, Marc Petit-Huguenin wrote:
> 
>>>
>>> The problem statement and some possible starting points for solutions are further desired 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
>>
>> VAP is not listed here.  Is it an oversight or is it because the WG will work
>> only on interoperability between ViPR servers?
> 
> I could go either way on VAP. On one hand, the minimal thing we need to standardize to have interoperability between domain is just the above stuff without VAP. On the other hand, VAP is a very simple way to modularize what is happening inside a domain. VAP allows information about PSTN call to be given to the server doing the VIPR stuff and allows the VIPR server to tell routing engines and PBX inside the domain about new routes. 
> 
> I'd be interested in hearing what other thing. It's easy to add something like VAP to the charter. 
> 

I do not plan to implement VAP and so will not be able to contribute on this
protocol if the WG choose to work on it.  So for what I am concerned, VAP does
not need to be in the charter, and I think that resources will be better spent
working of stuff that directly affects interoperability (and with SIP in the
equation there will be no shortage of interop issue).

This said, the VAP I-D is a mandatory reading to understand the behavior of a
ViPR server, so there will be at least a need to split the VAP protocol from the
ViPR server behavior.

- -- 
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)

iEYEARECAAYFAkwX/poACgkQ9RoMZyVa61f8yACgmbFovAvocpMTKoZyznHanYmX
JPIAn1H8eGxHHP7PV5AEkwCaiZh1sfab
=quJ4
-----END PGP SIGNATURE-----

v2.23.0 | Report a Bug | By Email