From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a "good enough" level of authentication and security.
ViPR appears to be the best candidate at this point. It has the advantage that it is self-contained and not reliant on any centralized mechanism. It is clearly not perfect and there will be issues which need careful consideration (including some of the security issues you have raised w.r.t. call id spoofing, number migration etc.).
Is there a specific disclaimer you would like to see added to the charter so these limitations are clearly set forth in the WG definition or is your objection irreconcilable?
Regards,
Peter Musgrave
On Mon, Jul 5, 2010 at 9:27 PM, Richard Shockey <richard@xxxxxxxxxx> wrote:
Thank you Brother Conroy... this is a full IETF discussion since it does
involve the creation of a new working group that does not seem to understand
what is actually involved in E.164 validation.
I do understand what this is really about..how do we screw global voice
service providers since the IETF has not been able to convince normal folk
to use SIP URI's.
A reasonable objective, but I haven't seen many SIP URI on the back of
plumbing or tree conservation trucks driving down my Reston VA neighborhoods
recently. HTTP URI's are another thing.
The real ultimate question is, can we, the SIP community, possibly learn to
live with E.164 in SIP in some rational manner? Phone numbers are not going
to go away as much as my dear friend Henry Sinnreich would prefer.
-----Original Message-----
From: Lawrence Conroy [mailto:lconroy@xxxxxxxxxxxxxxx]
Sent: Monday, July 05, 2010 7:46 PM
To: Richard Shockey
Cc: Paul Kyzivat; DISPATCH
Subject: Re: [dispatch] VIPR - proposed charter version 3
Hi Richard, folks,
[removing ietf-general as cross-posting this whole thread doesn't help,
IMHO]
I have remained silent so far, but just to clarify...
Richard is absolutely correct.
The comments on ENUM seemed to miss WHY public ENUM has been hard to roll
out.
Each country (or region) has its own idea of Eligibility criteria for ENUM
domain registration in its jurisdiction.
One thing they pretty much every one of the authorities agrees on is that
*AT LEAST* there has to be a demonstrable proof that the domain owner is
provided (or provides) service via the associated E.164 number.
To say that this is a challenge to arrange cheaply or simply (or at all)
is an understatement. Trust me; I know to my cost, as does Richard.
Even that does not demonstrate that a value published in an ENUM domain
MUST be, by some guarantee, always tied to that domain and its associated
E.164 number. If I own a domain, I can provision what I like in that domain.
The validation "hook" is tied some way to the numbering authority for E.164
numbers in a particular jurisdiction, and there IS no validation authority
that ties a SIP URI to an E.164 number.
In private ENUM clouds, carriers "know their own" and trust partner carriers
(at least partially). That's a set of contractual agreements, nothing more.
The real question you have to ask is: can you gain access to the basic
information on which the private ENUM domains provisioning is based?
If you are part of that federation, then yes (at least you can query the
private ENUM tree).
If you are outside that federation, then no protocol magic is going to
change that fact.
Sorry for the long post, but it isn't a protocol issue; that well be
LDAP (or something that scales). It's an operational and contractual
agreement between CSPs, and last I heard that was not an IETF topic.
all the best,
Lawrence
On 5 Jul 2010, at 19:48, Richard Shockey wrote:
> my assertion is that any authentication of the
> responsible domain for a E.164 number outside of the PSTN service provider
> or national numbering authority is not possible under the current
regulatory
> circumstances.
_______________________________________________
dispatch mailing list
dispatch@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf