Re: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-pvp-03.txt

Marc Petit-Huguenin <petithug@acm.org> Thu, 23 February 2012 15:26 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 2790E21F841C for <vipr@ietfa.amsl.com>; Thu, 23 Feb 2012 07:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.381
X-Spam-Level:
X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, 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 GIu5V4ROQOuq for <vipr@ietfa.amsl.com>; Thu, 23 Feb 2012 07:26:15 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 26DF121F85C4 for <vipr@ietf.org>; Thu, 23 Feb 2012 07:26:15 -0800 (PST)
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 0358520414; Thu, 23 Feb 2012 15:10:08 +0000 (UTC)
Message-ID: <4F465A93.1000208@acm.org>
Date: Thu, 23 Feb 2012 07:26:11 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
References: <20120213193014.13407.27019.idtracker@ietfa.amsl.com> <4F39687B.1090102@acm.org> <29D6EC8A-BD2E-47AB-AA6F-FE1AE46F5A3B@iii.ca>
In-Reply-To: <29D6EC8A-BD2E-47AB-AA6F-FE1AE46F5A3B@iii.ca>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "vipr@ietf.org" <vipr@ietf.org>
Subject: Re: [VIPR] Fwd: I-D Action: draft-petithuguenin-vipr-pvp-03.txt
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: Thu, 23 Feb 2012 15:26:17 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/22/2012 03:58 PM, Cullen Jennings wrote:
> 
> If an x- method turns out to be a great thing, how does it migrate to being
> a non x- ?

Simply define the new method in an RFC, and start adding the method in
ViprRegistration.  The only minor inconvenience is that during the transition
period the PVP client will, in the worst case, try both the experimental and
the standard method.  This can be prevented if the PVP client explicitly knows
that a specific standard method replaces a specific experimental method.  The
simplest would be to add this in the list of data that the RFC defining a new
method must provide.  Then we just need some text in -pvp that says that a PVP
client must only try the standard method if such relationship exist and if the
ViprRegistration record contains the two methods.

So lets say that domain A developed a new experimental method x-z and is
testing it with  domain B, so they both publish all their phone numbers with
{x-z,a,b}.  Later A decides to publish an RFC that assigns z to the same
method.  Domain A updates all its phone numbers with {x,x-z,a,b}.  Domain B
still had not updated so it does not use x.  Domain C updates with {x,a,b} and
start using z with domain A.  Later domain B updates with {x,x-z,a,b} and now
when verifying with A has the choice between x and x-z.  Because the
implementation of x knows that it is a replacement for x-z, it simply skips
x-z if both are present.

Now the last missing piece is to know when domain A and domain B should stop
publish ViprRegistration records with x-z.  I propose to also ask the authors
of the RFC defining the new method to put a date limit in the spec.  That
would look something like this:

  'The method name defined by this document, "z", is a replacement for the
experimental method "x-z".  Implementers MUST stop adding method name "x-z" in
published ViprRegistration records two years after the publication of this
document as RFC.'

> 
> On Feb 13, 2012, at 12:46 PM, Marc Petit-Huguenin wrote:
> 
> Instead of trying to fix everything at the same time, I decided to release 
> incremental modifications of the VIPR specs.
> 
> This new version of -vipr-pvp adds some text establishing the IANA
> registry for PVP methods, as was agreed (section 11).  Some details I added
> since the last time we talked about this:
> 
> - Private methods start with "p-" and cannot be used between domains[1]. -
> Experimental methods start with "x-" and the reversed domain.
> Experimental methods may be registered by IANA. - The algorithm to assign
> priority is to use the median between the next method and the previous
> method to try.  This means that method "a" has a priority of 0, method "b"
> has a priority of -16384 ((-32768 + 0) / 2), and method "c" will have a
> priority of 16383 ((0 + 32767) / 2) if we decide that it should be tried
> before method "a" or -8192 ((-16384 + 0) / 2) if we decide to try it after
> method "a". - Multiple methods can have the same priority (I think that we
> talked about this in Taipei).
> 
> Comments, questions, suggestions welcome.
> 
> Thanks.
> 
> 
> [1] The reversed domain name is mandatory for private method, which does
> not make sense.  This will be fixed in the next version.
> 
> -------- Original Message -------- Subject: I-D Action:
> draft-petithuguenin-vipr-pvp-03.txt Date: Mon, 13 Feb 2012 11:30:14 -0800 
> From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To:
> i-d-announce@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> Title           : The Public Switched Telephone Network (PSTN) Validation 
> Protocol (PVP) Author(s)       : Marc Petit-Huguenin Jonathan Rosenberg 
> Cullen Jennings Filename        : draft-petithuguenin-vipr-pvp-03.txt Pages
> : 31 Date            : 2012-02-13
> 
> One of the main challenges in inter-domain federation of Session Initiation
> Protocol (SIP) calls is that many domains continue to utilize phone
> numbers, and not email-style SIP URI.  Consequently, a mechanism is needed
> that enables secure mappings from phone numbers to domains.  The main
> technical challenge in doing this securely is to verify that the domain in
> question truly is the "owner" of the phone number.  This specification
> defines the PSTN Validation Protocol (PVP), which can be used by a domain
> to verify this ownership by means of a forward routability check in the
> PSTN.
> 
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at: 
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at: 
> ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-03.txt
> 

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

iQIcBAEBCAAGBQJPRlqRAAoJECnERZXWan7EMtgQAOJT+jHC0F8YCcGSzquMvIsr
Ur0KXK6usTv8VZmojXBUOmqNLQMB/31Q3rsVV4bAY1o9HQt+xrfBUORzMKi3Sbfw
JmEbanLVB+lJXsZd5I7J70hMy5CxYzZgFJZoZ/c7RNYgkwKeMsZm2cNpiVR1GRSn
JefSmEC3cnLLT+vzUDhIFgkWyK/vTHmfNLAxqNBWUw2qLUHlR6B5QPJNt0W8vjtz
N+BSPjRPgZ61vINP76ZhMtQImiw1wYQ9I1r/lbXONE8TrcrVU0ZB9QnqjvzFTMtz
QMvMWRPgzCX7wzwqtC+QfRYoWPVoElW0vThZ5056x2XoirCo2JT1cPx77RxPtKdS
/qgprrImY3Db4RPZIdUVE110k+PB6aQhqaOLFTTtMttLCngFwxayQLKBmaojmyZZ
7skGE5xfIEkW/s5WTZztpDXTYGoK3aL1zdyRP4Mvq0COXF5Y1A7RWDYTE/cAhk4h
7audiQ5916gaRm09BaCNiyf4mtgiB43VXa2YLidu2TbF9z4fS5waJ4fNlel35P//
qgTJiAxumAtUviMKQK6bW/zHi1XZiH/N1WsjZ2vGqfmt+LUABKdn408jrsfEaxir
9JMtnzBwTCr4LDP4rgxXUWpAcj1y27zo6fmpqcIVRC4WmA4NapVul+7R2iocGb+X
alo8FeeN8+NcKg8ot7+F
=m3b/
-----END PGP SIGNATURE-----