Re: [dispatch] VIPR Charter

["Richard Shockey" <[e-mail]>]

On 01/12/2011 07:09 AM, Richard Shockey wrote:
> I still don't see how you can write a charter without dealing with the
> Number Portability issue. You really need to be explicit that this proposed
> methodology WILL FAIL in cases where the PSTN authority for the phone number
> changes. It just needs to be called out.

I am not sure that I understand why the methodology would fail in this case
(there will be a transition period after porting to another ViPR enabled
provider, 

What is a ViPR enabled provider?  Provider of what? 


during which the SIP call will fail).  But for the sake of progressing
this charter, does the sentence "Validation protocols will be developed to
ensure a reasonable likelihood that a given domain actually is responsible for
the phone number" in the second paragraph covers your concern or do you require
a stronger wording?

First a domain is not and never will be "responsible" for a phone number. Only the NRA authorized carrier of record is "responsible" for the number.  ViPR is only a transient mapping technique for a arbitrary name held by a domain (E.164) to a URI(s) distributed in a p2p manner. Those mappings, shall we say typically have a long "TTL". 

Once the underlying number has been ported to another PSTN authority or disconnected its underlying authority is altered.

> 
> Plus I really take issue with the case that private federations don't scale.
> There is no evidence of that at all. IN addition its really irrelevant to
> discuss why ENUM in e164.apra did not deploy. Needless to say when you do
> have the cooperation of governmental or service provider administrative
> entities within an jurisdiction it can and does work well.

OK, would there be a consensus to rewrite the 3rd and 4th sentence of the first
paragraph as follow:

"Other approaches such as public ENUM or private federations are not sufficient
due to lack of widespread deployment."

Nope just delete the sentence.  You do not need to justify why you want to do this based on some arbitrary perception of why ENUM or private federations may or may not have been deployed.  I can assure you they have deployed. What we both know and you won't or can't say is currently those federations are controlled by the same NRA authorized carriers of record you want to route around. 



> 
> I certainly don't have any real issue with this work going forward. I'm a
> great fan of letting folks actually do things they want to so long as it is
> explicit what the limitations are. I'm sure there are folks that can and
> would use this technique. I only wish those who continue to oppose the
> extensions of ENUM for E2MD for instance would be as charitable. 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Marc Petit-Huguenin
> Sent: Monday, January 10, 2011 5:19 PM
> To: [e-mail]
> Subject: [dispatch] VIPR Charter
> 
> On the advice of the DISPATCH chairs, I am reposting below the latest
> version of
> the VIPR charter for additional feedback.
> 
> They are not considered as candidates for WG documents under this charter,
> but
> FYI the ViPR drafts were last updated in October 2010, and will probably be
> updated again before Prague:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-0
> 4.txt
> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-reload-usa
> ge-03.txt
> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-pvp-03.txt
> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-sip-antisp
> am-03.txt
> http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03.txt
> 
> Thanks.
> 
> ------------------------------------------------------------------------
> 
> VIPR Charter Proposal (Version 4)
> 
> WG Name:  Verification Involving PSTN Reachability (VIPR)
> 
> There are two globally deployed address spaces for communications used
> by more than a billion people daily - phone numbers and DNS rooted
> address such as web servers and email addresses. The inter-domain
> signaling design of SIP is primarily designed for email style addresses
> yet a large percentage of SIP deployments mostly use phone numbers for
> identifying users, thus DNS lookups are not sufficient. Other approaches
> such as public ENUM are not sufficient due to lack of widespread
> deployment for non-technical reasons - i.e., the involvement of
> government and service provider administrative entities needing to
> approve and populate the registries.  Private federations have been
> established to workaround the issue, however, that solution is not
> scalable. The goal of this working group is to enable inter-domain
> communications over the the Internet, using protocols such as SIP,
> while still allowing people to use phone numbers to identify the person
> with whom they wish to communicate.
> 
> The VIPR WG will develop a peer to peer based approach to finding
> domains that claim to be responsible for a given phone number
> to mitigate the involvement of centralized entities to avoid some of
> the issues encountered by past attempts to support SIP inter-domain
> communications. Validation protocols will be developed to ensure a
> reasonable likelihood that a given domain actually is responsible for
> the phone number. In this context, "responsible" means an
> administrative domain, which is at least one of the domains, to which
> a PSTN call to this phone number would be routed. Once the domain
> responsible for the phone number is found, existing protocols, such
> as SIP, can be used for inter-domain communications.
> 
> Some validation protocols may be based on knowledge gathered around a
> PSTN call; for example, the ability to prove a call was received over
> the PSTN based on start and stop times. Other validation schemes, such
> as examining fingerprints or watermarking of PSTN media to show that a
> domain received a particular PSTN phone call, may also be considered by
> the working group. This validation will be accomplished using publicly
> available open interfaces to the PSTN, so the validation can be
> performed by any domain wishing to participate.  The WG will select and
> standardize at least one validation scheme.
> 
> The validation mechanism requires a domain to gather and maintain
> information related to PSTN calls.  This information is used by call
> agents such as phones, SBCs and IP PBXs to route calls.  The WG will
> define a client-server protocol between these call agents and the entity
> within a domain that maintains the information.
> 
> To help mitigate SPAM issues when using SIP between domains, the WG will
> define a mechanism to enable one domain to check that incoming SIP
> messages are coming from a validated phone number.  A phone number is
> considered validated if it is coming from a domain to which the calling
> domain had previously successfully placed a PSTN call.  The working
> group will define new SIP headers and option tags, as necessary, to
> enable this.
> 
> The essential characteristic of VIPR is establishing authentication by
> PSTN reachability when it is not possible to use a direct reference to
> ENUM databases or other direct assertions of PSTN number
> ownership. Elements such as public ENUM easily coexist with VIPR but no
> direct interaction with ENUM will be required.  The solution set defined
> by this WG will be incrementally deployable using only existing
> interfaces to the PSTN.  No changes will be required to existing PSTN
> capabilities, no new database access is needed nor is any new support
> from PSTN service providers required.
> 
> The WG will produce the following deliverables:
> 
> 1) A document describing the requirements, problem statement and
> architectural approach to support SIP inter-domain communications.
> 2) A document describing the use of the p2psip protocol (RELOAD) as
> applied to this problem space.
> 3) A document defining a scheme for validating the phone numbers using
> publicly available open interfaces to the PSTN.
> 4) A document defining client-server protocol between call agents and the
> entity within a domain that gathers and maintains information related to
> PSTN calls.
> 5) A document describing a mechanism to mitigate SPAM issues.
> 
> The working group will carefully coordinate with the security area, O&M
> area, as well as the appropriate RAI WGs such as sipcore and p2psip.
> 
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch

- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0t5aUACgkQ9RoMZyVa61c4jACfXdtftBvrLYklzYINuzfEmQg1
/rgAoJgKU5HW0Qie8JRfCmKZsWw20aOR
=WaTf
-----END PGP SIGNATURE-----