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

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 13 Feb 2012 11:46:03 -0800

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Feb 2012 16:58:22 -0700

If an x- method turns out to be a great thing, how does it migrate to being a non x- ?

On Feb 13, 2012, at 12:46 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJPOWh6AAoJECnERZXWan7E9KMP/16vNLepmHpgqWX//eUuU/Ov
> RCSIkUEeol3udn1o6d3NIOQpO5PYYV80BXO/R2ZjHXZFq2ByZ1C/oVTHsiMaSSQx
> 2/c33qT3nTvVpS/TBvptVUTP1Nf9GU9/VnP+hIL+Cr5Jw2Atr5t/GnGs+DODH8Xj
> jBLnEwBB5pzQ5Wm/G1WD088fvqJ38CH/GXnzeYflLT4WCzcc/uL3z4SVFiYAw6Zs
> 8aEpzfYAtk9sSaYFvtMaF19RfoT5BK/s3GW64ahQKDWw8yZrhJmIeGGtuahhqVS7
> F4x+QqUkFC3ao2dr2/aPh164qKghJJz8PVXFp4X5jwlx/Y3KzlGx3wToe3NvSLiT
> ALp9dL/lcRKwc76MiiRKu+ZKrFqUBwmeJ8W8HtxH+cNh/f1geDsgdIDobJ9wVZas
> eQUx68swUhK8BAVIRMG6UiVbC2Gy/KmgjIzvtPBOmsPebm7J1Ir1fAVzCa7timk7
> kMUwgeC0sJ1fXAtI/zPQvqSB9ibRjTRZQGP7xzgkgbhgMgPJIxFFuDnnd8vVUaUK
> IAPXJso9DTNyQQhq/KexROWUx1JSQh6rj7pqSGOweENknKccBnmB9LWf4pSdCDlV
> /BRSXbMAm0nb1uSprID5Ovc5+Ag1mLEAmhSoEJCZvsJTSAVzti4kHmkj9sSEe39B
> mci38Zi7O9T0FWrEv4Ug
> =Ox5X
> -----END PGP SIGNATURE-----
> _______________________________________________
> VIPR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vipr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 23 Feb 2012 07:26:11 -0800

> If an x- method turns out to be a great thing, how does it migrate to being

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.'

> 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).
> 
> [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: [email-masked] Reply-To: [email-masked] To:
> [email-masked]
> 
> 
> 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.
> 
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org