[VIPR] A new proposal for SIP Intermediaries

Marc Petit-Huguenin <petithug@acm.org> Mon, 03 October 2011 17:24 UTC

Return-Path: <petithug@acm.org>
X-Original-To: vipr@ietfa.amsl.com
Delivered-To: vipr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C196B21F8C17 for <vipr@ietfa.amsl.com>; Mon, 3 Oct 2011 10:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.161
X-Spam-Level:
X-Spam-Status: No, score=-101.161 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, MANGLED_TEXT=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x77t+oQHQh4d for <vipr@ietfa.amsl.com>; Mon, 3 Oct 2011 10:24:49 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A1E4721F8C2B for <vipr@ietf.org>; Mon, 3 Oct 2011 10:24:48 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8AFD6202D1 for <vipr@ietf.org>; Mon, 3 Oct 2011 17:20:58 +0000 (UTC)
Message-ID: <4E89F095.3070301@acm.org>
Date: Mon, 03 Oct 2011 10:27:49 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13
MIME-Version: 1.0
To: "vipr@ietf.org" <vipr@ietf.org>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: [VIPR] A new proposal for SIP Intermediaries
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2011 17:24:49 -0000

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

For the second time, the Design Team conference call got stuck on the subject of
SIP intermediaries in VIPR, and we were not able to make any progress on the
VIPR specifications themselves.  I was supposed to send another email to this
mailing-list to describe in more details the problems created by SIP
intermediaries but I fear that the next conference calls will still being spent
arguing about this.  So I would like to propose an alternate route to solve this
issue.

SIP intermediaries are not described at all in the current specifications, but I
think that everybody agree that we should say something about it, because it
will become a reality, even if we decide to make it a SHOULD NOT (which would
exclude a lot of potential participants from the VIPR federation).  On the other
hand, VIPR domains does not require SIP intermediaries to work.

So my proposal is:

1. Put everything related to SIP intermediaries in a separate I-D, so it does
not hold the main specifications.
2. Add in the main specifications the "hooks" required to be able to add support
for SIP intermediaries as an extension in the future (as opposed to have to work
on a new version of the VIPR RFCs to add SIP intermediaries, which will push
back the deployment of SIP intermediaries for another 3 years).
3. Add a new milestone for the SIP intermediaries (I would suggest April 2012[1])

Please let me know as soon as possible if you agree with this new plan, at least
on the two first points, so I can release the first version of the new
draft-petithuguenin-vipr-sip-intermediaries I-D, and so we can move one on the
other subjects that are actually blocking the work on -framework.

Thanks.


[1] And I would also suggest to move at the same time the "Submit Specification
of authorization tokens to mitigate SPAM for publication as Proposed Standard"
to December 2011, as it make sense to submit this at the same time than the
other core VIPR specifications.

- -- 
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.11 (GNU/Linux)

iEYEARECAAYFAk6J8JMACgkQ9RoMZyVa61ckLQCgpM/sND37krkNZRPWrQt4deHF
dRMAnAmG7FZFFaIU7xNC+oHUIChQGU/C
=t3x7
-----END PGP SIGNATURE-----